[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, 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?


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?


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

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.

That's all for now, gotta catch a train.

Cheers,
Sandor

Sylvain Wallez wrote:
Hi all,

I asked Bjorn Freeman-Benson this week (he's the technical director, open source process and infrastructure of the Eclipse foundation) about the things that have to be done within the proposal phase of an Eclipse project.

He was just coming back from vacation and didn't had time for much details, but here's the interesting quote: "The end of the review period is when it appears that the discussion has properly gelled around the concepts and ideas. In your case, because you're so focused and organized, this will be shorter than for other projects. It may even already be true."

Good news. However, even if the Lepido proposal [1] contains a number of features, and many people expressed their interest in the project when I announced it, not much people provided actual feedback since this newsgroup was opened.

Chicken and egg problem, I guess people are waiting for the code to land in CVS to start being more active, but we won't have the CVS until enough feedback has been given (remember however that my company's plugins and their source are already available for download [2]).

So, what do you think of the planned features? Does they fit with your view of a Cocoon IDE? What other features would you like to have?

Please provide us feedback either here or on the wiki page [3].

Thanks,
Sylvain

[1] http://www.eclipse.org/proposals/eclipse-lepido/
[2] http://people.anyware-tech.com/~sylvain/lepido/com.anwrt.eclipse.lepido.zip
[3] http://wiki.apache.org/cocoon/LepidoProjectPlan