[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.lepido] Re: What features do you want for Lepido?

Sandor Spruit wrote:

Sylvain Wallez wrote:


<snip/>

Sorry, I don't really understand this. What "resources" are you
talking about? Can you elaborate with an example?


Like you mentioned above: flowscript or form definition refers to a
pipeline, quite implicitly, working by association. You mentioned this
in another thread. It can't be too difficult to scan a flowscript for
calls to 'sendPageAndWait', check sitemaps for the pipeline mentioned.


Hmm... checking for "sendPageAndWait" is certainly easy. Now finding the corresponding pipeline may not be that easy, unless we rewrite a lightweight sitemap engine (e.g. only basic matchers and selectors).

Same story: create HTML in a XSLT stylesheet, introducing an IMG tag
that refers to an jpg-image while your sitemap does not have a pipeline
for jpg's, or the image file cannot be found on the file system.


Wow, even more hard to find IMO. Do you have some ideas in mind about how the underlying semantic and analysis model?

<snip/>

Ok. See my previous answer to Stavros about "snippet wizards". Is
this what you're talking about?


I'll quote you here to ensure we are talking 'bout the same thing:
"Yup. The problem I see coming with the semantic model that we'll have
to build is that many files in Cocoon depend on other files, but this
dependency isn't explicit. For example a subsitemap depends on its
parent sitemap but doesn't link to it. Same applies to a form
definition, template and binding which are all glued together by a
flowscript."

This is *exactly* why Cocoon is difficult to teach. Or indeed any web technology. Implicit interdependencies. The really appealing aspects of Cocoon require a larger context. Larger then folks that are "into it" realize. If you could combine technologies in a scenario or wizard, the power of Cocoon would be more visible and it would be easier to use.


You're right. We'll have to find a way to extract these dependencies, at least for the most common and most "static" cases. These are the ones most likely to be used by newcomers, and will help them getting started, and others be productive. But the danger is to want to go too far in the analysis and then fall into too much complexity.

BTW, no need to send me a private copy of what you send here. I monitor this newsgroup quite closely :-)

Sylvain

--
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director