Hi Jason
Thanks for your comments. That is a lot of information there. I will
take a bit of time to understand its ramifications. I am very much
interested in taking ACMS to completion with or without Cheyenne. In
fact, I already have a journal management system that I plan to do using
ACMS. Usually there will be the 20:80 rule at work (A lot can be
achieved in 20% of the time but to achieve the balance one needs 80% of
the time) One way to beat the 20:80 rule is to think of 200% things to
implement, so I guess all this are steps in the right direction.

Regards
Sabu Francis

Jason Cunliffe wrote:
> 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.

Reply via email to