>
> So, I came to a conclusion that what Cocoon's
> documentation lacks is an
> ideological or conceptual papers. There's a lot of
> information in mailing
> lists, but it's mostly technical: how to do this or
> that. Less often and
> scattered is info on 'why' you do this and that in
> some particular way. It's
> like to tell that a car has 4 weels, but not to tell
> why it has them, why
> there are 4 of them. So, when a guy downloads
> Cocoon, runs samples, he ends
> up with a question: how to use it?
I tend to agree with you here. Cocoon is excellent
software, but the broader potential user community
is in need of more hand-holding (i.e. they are
not up for the more technical reverse engineering
and research task compared to our present
user community group).
> Here's the idea: why not to allow bypass Web GUI in
> Cocoon. Maybe sitemap
> must be gone too. So, there must be means to build a
> Cocoon powered system
> in such a way, that I can see what components are in
> Cocoon and use them
> deliberately. Suppose, I launch URL: /generators/dir
> and get the list of
> generators. Then I say:
> /generators/xsp/bla-bla@/serializer/html/ya-da-da
> This will be my command line to launch a generator
> then forward it to a
> serializer.
> Or like this:
> /generators/xsp/bla-bla@/temp/a
> This would store the output in the temporary URL:
> /temp/a, so it can be used
> instead of the generator later on.
You "could" do this, but why would you want to?
That is, aside from it being something "cool"
can you describe a more realistic application
in which this would be used?
It seems to me you would just be pushing business
logic into another area.
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
