[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:

Sylvain, others,

My 2 cents follow.

Key feature: being able to trace information flowing through Cocoon
from the moment a http request comes in. What components are
triggered? What information is exchanged between these components?
I think that's what people mean by a sitemap debugger?

Yep, but there's more to processing flow than only the sitemap. I'm sure we'll want to step from the sitemap into a flowscript, then from the flowscript back to the sitemap. See also my previous post about this.

Sure. My component definition is broad enough to cover flowscript as well :) Technically not correct, practically true. Perhaps I should say building block and not component.

Really nice: check the sitemap against other files for consistency.
Many places in my Cocoon apps refer to the sitemap. FlowScript contains links to pipelines, stylesheets contain references to
files that have to be matched with a pipeline. I often find myself
testing a Cocoon sniplet to find, for example, property files or
pictures unreferenced in sitemaps. Quite stupid, quite simple but
soooo easy to overlook. Could we scan the files for (relative)
URLs pointing to unmatched resources? Maybe a view on your project
where sitemap (left pane) and other elements (right) are combined?
A warning message when you add a resource to a project?

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.

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.

Along the same line: having several sitemaps and subsitemaps where
 some construct in the subsitemap won't work because there's an
overlap with a higher level sitemap. Not an error condition in the
strictest sense, but so easy to overlook. Frustrating. I seem to
remember that it's possible to check whether a regular expression
is a specialization/generalization of another regular expression?
Think: **/*.jpg and simple *.jpg

Definitely interesting, even if that requires a bit of "intelligence" in the sitemap editor. It often happens in a single sitemap also. This feature will require that we have some kind of semantic model of the Cocoon application. A first version of this model can consist in building the tree of match patterns to be able to quickly find such overlappings and what pipeline will answer to a request. This model won't be able to detect everything though, as it will be limited to those matchers that can be executed without a runtime environment. But with just regexp and wildcard matchers, we already cover a large number of cases.

Definitely.

I like the idea of wizards. I think it would be easier for new
folks to grasp the Cocoon concepts if some frequently occurring use
cases would be 'prepared' in a template for them. I have recently
looked at Cocoon as a tool in our curriculum. Top issue: how to
explain the relationships between technologies? Part of the beauty
in Cocoon's design is that some *combination* of relatively simple
technologies solves a problem. Not a big fat concentrated blurp of
complexity. Consequence: you have to focus on everything working
together. And that's not really easy. A wizard maybe an excellent
idea to address this, as you can illustrate how your solution is
built-up which is better then an comprehensive example IMHO.

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.

Sandor