Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 73685 invoked from network); 28 Feb 2006 00:56:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Feb 2006 00:56:53 -0000 Received: (qmail 58528 invoked by uid 500); 28 Feb 2006 00:56:51 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 58431 invoked by uid 500); 28 Feb 2006 00:56:50 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 58420 invoked by uid 99); 28 Feb 2006 00:56:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2006 16:56:50 -0800 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of irv.salisbury@gmail.com designates 66.249.82.192 as permitted sender) Received: from [66.249.82.192] (HELO xproxy.gmail.com) (66.249.82.192) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2006 16:56:49 -0800 Received: by xproxy.gmail.com with SMTP id s14so342563wxc for ; Mon, 27 Feb 2006 16:56:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Enu18gU/0za3EHuqDxvX76+AZqOu2mcrJ/jAbmx4tO9EGFKMrTmeE7Kq8sBhdL5Q/lDDe+kHqa7rnLs4OWI50yzyATqf771Iy3JHchZb7lkKhCdtrsNqtr2Tv16w7dOOUPu/P+7ukIMBmmiZPaEtYgvoIJ8HNhhpBV7ivCa9sts= Received: by 10.70.45.2 with SMTP id s2mr60704wxs; Mon, 27 Feb 2006 16:56:28 -0800 (PST) Received: by 10.70.86.13 with HTTP; Mon, 27 Feb 2006 16:56:28 -0800 (PST) Message-ID: <8b8d97d20602271656y76d75559rceb5af58292ade9@mail.gmail.com> Date: Mon, 27 Feb 2006 19:56:28 -0500 From: "Irv Salisbury" To: dev@cocoon.apache.org Subject: Re: [CRAZY IDEA] sitemaps in javascript In-Reply-To: <43E05061.4020405@agssa.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16226_8562024.1141088188302" References: <43DE3CAC.300@apache.org> <693885884.20060131130106@maukisch.net> <43DF6B20.5010101@apache.org> <138409517.20060131153150@maukisch.net> <43DF7D2C.1080204@apache.org> <43E05061.4020405@agssa.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_16226_8562024.1141088188302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have to admit that the cocoon sitemaps we use for our projects have gotte= n out of hand. If a new person started working on it, they would need a sitemap for the sitemaps. Because of the common stuff we want to do across projects, we actually start with sitemap xml snippets that we include with DTD includes. (Yes I know it is ugly but the best we could come up with fo= r common sitemap stuff without true includes) Now, once you get past that, there are a ton of common resource calls with parameters. Each of these uses aggregation and the cinclude transformer. The cinclude transformer of course has calls to cocoon:// pipelines. So, now the spaghetti starts getting nasty. All of this is in the name of reus= e and without having true inheritance and an easy aggregation mechanism, we have had to do these things. Add in the mix of flowscript and you really have a nightmare on your hands. We have tried to keep to rules of what goes where, but somebody new coming onto our project would need at least a couple weeks and a roadmap to find their way around. Having a nice, clean include mechanism and an easy inline way of doing aggregation, coupled with the ability to do easy content based routing (yea= h don't get me started on that one) and our sitemap would be a LOT cleaner. We accomplish content based routing by using XMLBeans, calling a pipeline that fills up the bean in flowscript, checking the values, then calling the appropriate other pipelines. The back and forth of this is pretty nasty. So, I would wholeheartedly agree that either javascript or java (my preference) for a sitemap language would be great. To offer the possiblity of not having to pass XML through the pipeline would be even better. For performance reasons, if I could just manipulate java (using hibernate or th= e like) the only go to XML for the final step is great. This can be accomplished somewhat with the current system, but you still have to go bac= k and forth from flowscript to sitemap, and get all the yuck with that. Irv On 2/1/06, Antonio Gallardo wrote: > > Sylvain Wallez wrote: > > > Experience showed that the sitemap language is actually very simple, > > and that people quickly find it more productive to write their sitemap > > with a content-assist editor. In this regard, the WebTools XML editor > > auto-learning feature does quite a good job once a sitemap contains > > one instance of each of the base instructions (match, generate, > > transform, etc). > > Here a fully commented schema for all the cocoon special files will help > a lot for newbies. > > > > > Now, to speak clearly, I'm thinking about closing Lepido at Eclipse, > > first because for a number of reasons on which I could expand it > > didn't attract people, and because the future of Cocoon is so unclear > > to me that investing in the development of a tool that may quickly be > > obsolete looks like wasted energy. > > Wow! :-( > I installed Lepido. I wanted to reach you sometimes to speak about the > Lepido future and how to start working on it. > > Best Regards, > > Antonio Gallardo. > > ------=_Part_16226_8562024.1141088188302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have to admit that the cocoon sitemaps we use for our projects have gotte= n out of hand.  If a new person started working on it, they would need= a sitemap for the sitemaps.  Because of the common stuff we want to d= o across projects, we actually start with sitemap xml snippets that we incl= ude with DTD includes.  (Yes I know it is ugly but the best we could c= ome up with for common sitemap stuff without true includes)

Now, once you get past that, there are a ton of common resource cal= ls with parameters.  Each of these uses aggregation and the cinclude t= ransformer.  The cinclude transformer of course has calls to cocoon://= pipelines.  So, now the spaghetti starts getting nasty.  All of = this is in the name of reuse and without having true inheritance and an eas= y aggregation mechanism, we have had to do these things.

Add in the mix of flowscript and you really have a nightmare on you= r hands.  We have tried to keep to rules of what goes where, but someb= ody new coming onto our project would need at least a couple weeks and a ro= admap to find their way around.

Having a nice, clean include mechanism and an easy inline way of do= ing aggregation, coupled with the ability to do easy content based routing = (yeah don't get me started on that one) and our sitemap would be a LOT clea= ner.  We accomplish content based routing by using XMLBeans, calling a= pipeline that fills up the bean in flowscript, checking the values, then c= alling the appropriate other pipelines.  The back and forth of this is= pretty nasty.

So, I would wholeheartedly agree that either javascript or java (my= preference) for a sitemap language would be great.  To offer the poss= iblity of not having to pass XML through the pipeline would be even better.=   For performance reasons, if I could just manipulate java (using hibe= rnate or the like) the only go to XML for the final step is great.  Th= is can be accomplished somewhat with the current system, but you still have= to go back and forth from flowscript to sitemap, and get all the yuck with= that.

Irv

On 2/1/06, Antonio Gallardo <agallardo@agssa.net> wrote:
Sylvain Wallez wrote:

> Experience showed that the sitemap langua= ge is actually very simple,
> and that people quickly find it more pr= oductive to write their sitemap
> with a content-assist editor. In th= is regard, the WebTools XML editor
> auto-learning feature does quite a good job once a sitemap contain= s
> one instance of each of the base instructions (match, generate,> transform, etc).

Here a fully commented schema for all the co= coon special files will help
a lot for newbies.

>
> Now, to speak clearly, I'm think= ing about closing Lepido at Eclipse,
> first because for a number of = reasons on which I could expand it
> didn't attract people, and becau= se the future of Cocoon is so unclear
> to me that investing in the development of a tool that may quickly= be
> obsolete looks like wasted energy.

Wow! :-(
I install= ed Lepido. I wanted to reach you sometimes to speak about the
Lepido fut= ure and how to start working on it.

Best Regards,

Antonio Gallardo.

------=_Part_16226_8562024.1141088188302--