//Hello List,
what's up with the dev-team??!
I also don't like the idea, that there is no core development anymore. I
believe there is some development, but mainly done by all the
implementers for their own needs. We are at a point where we adapt
antville to our own needs - and we would like to contribute everything
that is usefull. But I think it needs somebody who puts it all together....
A quick answer to Tobi from my point of view
> -the current antville design resists flexibility and modularization
I don't think that it is too bad. I have done some changes in the system
and it took me less time than i expected. I have some problems with the
modularization with .zip files. It's fine if you deliver the module, but
for development it's not so nice. (But maybe that's just because i am
not through all Helma functionalities :( )
There are some parts of Antville that could be done in a. (e.g. the
memberMgr )
> -there's lack of supportive giving back from other antville
developers (instead we have a strange competition of the same product
with two different names).
What do you mean here?
> e.g. to implement a new action i do not only need to know a little
bit too much about antville's internal access permission management – i
even have to write every permission check (i.e. whether a user is
allowed to create, update or delete an item) mostly from scratch.
If you have an idea how to do this easier, please let us know ;) Maybe
it's better not to define individual user-rights in initconstants but to
refer to the Roles directly in the Security Functions. Or ist there a
way to extent the user-rights in different modules right now?!
>and even displaying a simple feedback message is quite a pain in the
neck due to and internationalisation engine that was half-heartedly
implemented and never finished.
aren't there already some solutions? I know e.g. of the twoday l10n.
> thus, my idea is to re-enable antville for easier development again.
the goal is to strip down the antville code to its bone by replacing any
inessential feature with a modular extension while simplifying the
remaining "chitin" skeleton to make it more understandable even for
regular (i.e. not helma-related) javascript developers.
Fine :)
>to achieve this i consider the following steps:
> -unify text, files and images to one hybrid content structure. this
way, any new item can be added without patching the database.
+1
> simplify access control by providing convenience methods that sort
out a user by verifying the necessary permissions with the actual role
privileges. a developer should be able to do this with one or at most
two function calls from an arbitrary action.
+1
> rework the whole internationalisation engine. here too, a developer
should only need to call a simple message funktion. and user's probably
should be able to edit message files from within their site environment.
+1 (what's with the already existing work?)
>improve skin handling and editing. as gobi <
http://gobi.helma.org/>
already shows there are ways to shift the input (i.e. editable forms)
and output skins towards each other. wouldn't it be amazing to only edit
one skin once and both, your text editor masks and the user front-end
appear just right and in sync?
I haven't had a look at gobis skin mechanism. But if there is a way to
do so- fine.
>delegate the user interface to the client again. client-side
javascript has become mature enough to use it for simple tasks like
paging and sorting; and as all the web 2.0 hubris and ajax cleansing
promise, it even could be used for fancier actions...
That's a way to go. But where is the line here. Which action should be
done by the client. And what's about clients with javascript deactivated?
>while we are at it: of course, antville could do with an appropriate
dose of (not so) recent hot web features. well, i did not say
"trackbacks" or "tags", but let's see what makes sense, here, anyway.
(tags for sure!)
I think tags are already done ;)
> yes, and all the rest (e.g. polls or blogger apis) goes into modules.
in fact, in modules every enthusiastic javascript developer should be
able to write.
+1
I'am currently reworking the memberMgr. I don't like the current design
here because it mixes the methods for a "Site Member Management", "Root
Member Management" and a personal view of the current logged in user all
together. So my idea is to make separate prototypes for each of them and
add all methods concerning a user to the "User" prototype. If there is
some interest in this attempt, please let me know.
Merry Christmas & Happy New Year,
Samuel
_______________________________________________
Antville-dev mailing list
Antville-dev@...
http://helma.org/mailman/listinfo/antville-dev
