cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Thu, 29 Jul 2004 07:19:48 GMT


Marcus Crafter wrote:

> On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote:
> 
>>But let not implementation details (or technics) drive the syntax.
>>It is more important to have a good sitemap language than to have 
>>a clean and small implementation.
> 
> 
> I agree too mate.
> 
> Something that I'm wondering about is what the relationship would be
> between flowscript and sitemap-script if we allowed the sitemap to be
> scriptable.
> 

as it is today: a function-call

what else could we call <map:call function="..." /> ?

> My first impression would be that the 2 would merge - the temptation
> would be there for our users to write their flowscript around their
> sitemap definition (good thing or bad thing?)
> 

the engineer's answer: it depends (as from a famous dilbert cartoon)

or the perl vision: make simple things simple and hard things possible

So if you choose to inline your function-call then in our current view 
we would see that as blasphemy, but for application X it might just be 
the correct thing to do.

> The XML syntax prevents keeps flow and sitemaps separate - perhaps its
> worth working out the relationship between both concepts?
> 

Very true, but subject to the existential question:

(paraphrazing Stefano in [1])
Is there a real (universally applicable) separation here?

If there is a need to separate (in your situation): you apply it by 
modularizing this new 'site-script' in modules and functions.  If it is 
not, then who are we to impose any way of working?

Rest assured I'm equally concerned with a number of other voices here 
about (using Ugo's wording) 'giving just more rope to hang yourself in'
However, when I see people 'removing and merging' then I can only see 
less rope :-)

IMHO we need to be honest/modest about how far any cocoon-user actually 
wants to be 'guided' and 'helped'.  One of the main explanations I've 
seen in the proclaimed 'tuff learning curve surrounding cocoon' is the 
'atomicity' of it's set of features: catch all or none of it, and thus 
truggle through quite a long period of frutration getting there...


Purely from a didactical POV I would love to be able to
- make a shortcut now and get this lesson over with
- rehash, modularize and add complexity in the next lesson
- and replace one lesson to learn that extra syntax by having more time 
for exercises

I honestly think Ugo is on the right track with his drive for 'simpler'

-marc=
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109103885629692&w=2
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message