Hi Sabu thanks for your notes. I've been looking into Anabelle further.. the more I read the more I like it ! It reminds me _conceptually_of ZOPE and its RESTful design. Zope is/was brilliant, but was just a hungry monster, even at birth. Keeping up with all the options and developments, meant printing about a suitcase load of docs each month. Its first version ate the entire development crew alive. Zope3 is another beast, claims to be tamed, but I am not so sure.
Anyway, been too busy all day with other work - not yet had time to get Anabelle running on Cheyenne. Just have to figure the various configs tweaks for linking in htdocs, paths - Where to put things ? But I think it will run nicely... This weekend hope to have time. Any specific tips you can offer now will be most welcome. My #1 *optimist* suggestion is that soon as you have time [after 2-Oct] you download latest Cheyenne and test ACMS on it ! Then report back to us all, and maybe in parallel with SoftInnov's blessings and participation, a joint Cheyenne-Anabelle [Cheyanabelle ??] easy-distro project could be set in motion This could help speedup docs, examples, demos etc. Get some nice group dev momentum going latest version is 13-July-2007 Cheyenne v0.9.16 download link and news at http://softinnov.org/cheyenne/blog.cgi VANILLA concept was genius, and still is, but needs a next generation effort Docs are almost non-existent or deeply oddly buried *Great features of Vanilla* - Snip dyna apps and those cool .metadata rebol block files [just waiting for Anabelle methinks] - selectors and template potential - nice easy access to file system - .metadata *What sucks about Vanilla* - hard to maintain; personal variants get out of sync fast - spaghetti confusion of form content and presentation - needs robust lucid templating and consistent CSS placement - security and permissions - backups, locking and management of simultaneous edits - insufficient role distinctions - System code is all mumbled and scrunched up with user code and content - No good mechanism for resolving simultaneous edits - No current means of collaborative editing. {I really want this} and think it is quite doable via clever use of metadata and inlcuding XMPP transport. We need something as versatile as Zope permissions. with the pragmatic gymnastic ability of TextPattern, simplicity of vanilla syntax, and cool strong concept of Anabelle :-) Thanks to rebol, Vanilla metadata files are one of the coolest things I've seen. So much one can/could do with them. Most of the features I plan are based on extending the creative access and uses of snip .metadata files One problem is that giving them more power means they are more of a security risk. However, reading your description of ACMS, I think vanilla .metadata files should be handled the same way, placed out of harms reach, only accessible through sysadmin back door controls, or well defined internal protected hidden functions and params. One of the things I lie about metadata blocks in vanilla is that you can use them to store system wide params, but also group or individual ones. Keywords, permissions, source and control references, stats, and template handling metadata. For example each snip can be assigned a block of template names and conditions. For example: if a snip .metadata has a 'default' template setting, then unless some thing else in vanilla overrides, then the snip will display with the named default template If it has an 'auto' template, then it will try to use that. In the same manner, 'next' or 'previous' could be used to define the next template to be used. This approach could really open up the MVC idea more lucidly and creatively than I yest seen in wikilog display for presentation design strategies. Sequences and play lists, remote control of web sequences... lots of good stuff to develop. What's been missing until now for Vanilla has been a strong extensible architecture to support such enhancements. I think you may have got it right. What remains to be seen is if Vanilla has to be completely re-written, how well Cheyenne performs and how well ACMS scales. If you like JQuery then also look into E4X http://developer.mozilla.org/presentations/xtech2005/e4x/ finally XML is not a nightmare :-) Jason Sabu Francis wrote: > Hi Jason > Thank you for your detailed inputs. I'll try and offer some explanations > > In the .7z file, there is already a small Annabelle based application > which can be used to develop a site that logs in users, saves forms > containing any number of fields as an ACMS object and reads out files > back into the browser. It demonstrates the power of ACMS inheritence > mechanism in the following manner: On the root of the server, both the > top and side menu of the website is displayed. But on the the sub-folder > within the site (/test/ ) only the side menu is displayed, even though > in both the cases the HTML file for viewing is more or less the same > (except for additional forms in the case of the second file, which > anyway does not have anything to do with the display of the menus). > > The second file (the index.html at /test/) has two forms. One can also > be used to create user registrations and the second does login (it sets > a cookie) I was creating the example as I was coding so it is probably > a very trivial example. I guess I need to document the step by step > construction of the site. I am going out of my country shortly and would > be back only on Oct 2, so I guess it would be after that. > > I am a big fan of Vanilla. It has a neat extension system. But I don't > think it has any OOPs mechanism. I was more of a user of Vanilla rather > than a developer, so I have not looked into its internals in detail. > However I too believe the concepts of Vanilla can be used along with ACMS. > > One of the main goals of ACMS is to cleanly apportion the development of > a complex website between various members: the overall website architect > (who would also probably work on the models used in the site), designers > (the one who sets up views), and programmers who write the controller > code. With JQuery it is possible to do very neat things, like visual > effects, AJAX, etc. The development work in JQuery is extremely fast. > The only downside is that for JQuery to work, Javascript has to be > switched on ... which I believe is on in most cases. > > ACMS has a natural connection with XML. It would be quite easy to port > XML into ACMS, and even out of ACMS. I do not know XMPP much but it > should be possible to get any XML structure into ACMS and then some more. > > Thank you very much > > Regards > Sabu Francis > -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
