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

Sylvain Wallez wrote:
Sandor Spruit wrote:

[snip]

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).

Now you know why I asked you about opening-up the sitemap API to tap into the sitemap's inner data structure - GetTogether in Gent.


Or is the sitemap engine so dynamic that it figures out all the details at runtime without building-up a true internal datastructure? Or maybe the entire structure is something like a compiled finite-state machine that is decoupled from the sitemap's pipeline definitions?

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?

Hmmm. Would it be difficult to have a sort of 'test-run' mode in the sitemap? I mean: given a certain URL pattern, just *tell me* which pipelines/components will be used, but do not take any real action?
Maybe that is what you mean by a lightweight sitemap engine?


<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.

True. We need a sort of "Cocoon design patterns" or use cases. Like all good things in life, the easier it looks, the more complicated it is :)


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

he he - will done :)

Sandor