forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: entry points [was:Re: Ok, I give up]
Date Thu, 18 Apr 2002 21:15:51 GMT
Diana Shannon wrote:

> Robert:
>
>> How about defining different entry points to cocoon. Example tracks:
>> 1. total newbie - very basic stuff to get them started
>> 2. experienced web developer but inexperienced at java or XSLT
>> 3. experienced web developer with java but inexperienced with XSLT
>> 4. inexperienced (serious) web developer that knows XSLT well
>> 5. ???
>
>
> Very good idea. We could develop audience profiles for these groups 
> that include assumptions about concepts most likely to need 
> reinforcement, based on pre-Cocoon preconceptions. This stuff pops up 
> all the time on the user list, like folks wanting to override a 
> serialization configuration from a stylesheet's xml:output method.
>
>> Everybody seems to be coming from cocoon at different angles. Define 
>> what is common to all and then split out to the entry points.
>
>
> Couldn't agree with you more. However, Cocoon as "glue technology" has 
> an extremely varied potential user base. 

Yes, that was what I was trying to address.

> Also, think about how many flavors of experienced web developer types 
> there are. I'm not saying it shouldn't/couldn't be done, but the 
> audience comes with a lot of potential "baggage."


I would keep #2 as generic as possible. Over time, the users can fill in 
the bulk of the specifics for a particular way in. I personally f,
this level of involvement would need a hierarchical organization of 
contributors - not common ownership... hence some type of user 
management. But that could be put off well into the future, I guess, 
until there is a solid system in place.

>
>
>> For something like #4, speaking from experience, I would like to see 
>> how you take an app that uses the XSLT/XPath document function to 
>> aggregate content and turn that into a cocoon app that aggregates 
>> content before the final transformation.  I could provide the 
>> XSLT/XML that aggregates content in the final transform using 
>> document(), but I would not trust myself to give the best cocoon 
>> conversion :(
>
>
> So how does that translate, ideally, into documents that fill up a 
> learning path? Is this a tutorial directed specifically at audience 
> #4? Or a combination of documents? If so, what types of documents?

I tried to use that as an example of - "here's how you do it with XYZ 
technology" - "and here is how we would optimize it for/with cocoon." I 
guess it would be a tutorial/philosophy thing.

Perhaps there is a page - "What do you want to do with Cocoon?" That 
page is set up to look like a well organized FAQ that strings the user 
out to something that they recognize. The path explores how they would 
normally do things and compares that to how it should be done in cocoon 
(always linking to more details). After they get exposed to cocoon in a 
light that allows them to see, the path takes them into the common 
cocoon learning/docs. That path brings them to the central idea of 
cocoon with respect to their needs.

best,
-Rob



Mime
View raw message