You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2000/09/01 14:00:08 UTC
Re: Aha! got it! 64k limit(was: new version of the sql
logicsheetunderdevelopment)
> From: Stefano Mazzocchi <st...@apache.org>
>
> Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be
> hard to port, anything else will be piece of cake.
Well, piece of cake or not, I have thousands of files, so I will need
some time to port. Plus, the "hacks" I had to implement for processing
chains should be put into the sitemap, this will also take some time.
And I suspect the clean-page model will not work anymore in cocoon2, so
everything needs to be converted over to the taglib-model. We are not
talking about simple pages here, but about sophisticated workflows. When
I think of some of the hacks that have been reported on this list to
make large sites work...
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Aha! got it! 64k limit(was: new version of the
sqllogicsheetunderdevelopment)
Posted by Stefano Mazzocchi <st...@apache.org>.
Uli Mayring wrote:
>
> "X-Ncc-RegID: de.denic"
> MIME-Version: 1.0
> X-MIMETrack: Itemize by SMTP Server on notes/Denic(Version 5.0.2c (Intl)|08 Februar 2000) at
> 03.09.2000 17:53:57,
> Serialize by Router on notes/Denic(Version 5.0.2c (Intl)|08 Februar 2000) at
> 03.09.2000 17:54:09,
> Serialize complete at 03.09.2000 17:54:09
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
>
> On Sun, 3 Sep 2000, Stefano Mazzocchi wrote:
>
> > Wrong. I invented the clean-page model, Ricardo the taglib-model and I
> > already publicly stated that namespace reaction is much wiser because
> > enforces MDSC much better.
>
> What is MDSC?
Multi-dimensional separation of concerns
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Aha! got it! 64k limit(was: new version of the sqllogicsheetunderdevelopment)
Posted by Uli Mayring <ul...@denic.de>.
On Sun, 3 Sep 2000, Stefano Mazzocchi wrote:
> Wrong. I invented the clean-page model, Ricardo the taglib-model and I
> already publicly stated that namespace reaction is much wiser because
> enforces MDSC much better.
What is MDSC?
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Aha! got it! 64k limit(was: new version of the
sqllogicsheetunderdevelopment)
Posted by Stefano Mazzocchi <st...@apache.org>.
Uli Mayring wrote:
>
> "X-Ncc-RegID: de.denic"
> MIME-Version: 1.0
> X-MIMETrack: Itemize by SMTP Server on notes/Denic(Version 5.0.2c (Intl)|08 Februar 2000) at
> 02.09.2000 22:06:44,
> Serialize by Router on notes/Denic(Version 5.0.2c (Intl)|08 Februar 2000) at
> 02.09.2000 22:07:06,
> Serialize complete at 02.09.2000 22:07:06
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
>
> On Sat, 2 Sep 2000, Stefano Mazzocchi wrote:
>
> > > And I suspect the clean-page model will not work anymore in cocoon2, so
> > > everything needs to be converted over to the taglib-model.
> >
> > This assumption is correct, but at the same time, the taglib-model is
> > nothing different from the clean-page model.
>
> Ha! Says the inventor of both models! But I am not entirely convinced, see
> my other mail to this list about this topic :)
Wrong. I invented the clean-page model, Ricardo the taglib-model and I
already publicly stated that namespace reaction is much wiser because
enforces MDSC much better.
> > This is exactly the point: I understand you are working on this and you
> > rely on the technology for your job, believe me there is nobody on this
> > list that respect this more than I do... but do you want to continue
> > with these hacks forever?
>
> I don't have too many hacks, at least nothing that couldn't be ported
> easily. But I wouldn't be surprised if the situation was different for
> guys like Mark Wasberg, who have really, really, really busy sites.
> > At the same time, we totally understand that C2 will be much different
> > from C1 so we'll make the path the smoother possible. This doesn't mean
> > there won't be bumps and back incompatibilities, there will be some, the
> > architecture is too different, but we'll make sure to ease this as much
> > as possible and we'll make C2 so irresistible that you'll feel ashamed
> > by still having to use C1 :)
>
> Sounds like a good plan to me :-)
Cool :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Aha! got it! 64k limit(was: new version of the sql
logicsheetunderdevelopment)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 2 Sep 2000, Stefano Mazzocchi wrote:
> > And I suspect the clean-page model will not work anymore in cocoon2, so
> > everything needs to be converted over to the taglib-model.
>
> This assumption is correct, but at the same time, the taglib-model is
> nothing different from the clean-page model.
Ha! Says the inventor of both models! But I am not entirely convinced, see
my other mail to this list about this topic :)
> This is exactly the point: I understand you are working on this and you
> rely on the technology for your job, believe me there is nobody on this
> list that respect this more than I do... but do you want to continue
> with these hacks forever?
I don't have too many hacks, at least nothing that couldn't be ported
easily. But I wouldn't be surprised if the situation was different for
guys like Mark Wasberg, who have really, really, really busy sites.
> At the same time, we totally understand that C2 will be much different
> from C1 so we'll make the path the smoother possible. This doesn't mean
> there won't be bumps and back incompatibilities, there will be some, the
> architecture is too different, but we'll make sure to ease this as much
> as possible and we'll make C2 so irresistible that you'll feel ashamed
> by still having to use C1 :)
Sounds like a good plan to me :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Aha! got it! 64k limit(was: new version of the sql
logicsheetunderdevelopment)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ulrich Mayring wrote:
>
> > From: Stefano Mazzocchi <st...@apache.org>
> >
> > Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be
> > hard to port, anything else will be piece of cake.
>
> Well, piece of cake or not, I have thousands of files, so I will need
> some time to port.
And will take months for C2 to stabilize... we are fully aware of this
and this won't happen overnight... you'll have all the time you need to
evolve your system.
> Plus, the "hacks" I had to implement for processing
> chains should be put into the sitemap, this will also take some time.
Sure.
> And I suspect the clean-page model will not work anymore in cocoon2, so
> everything needs to be converted over to the taglib-model.
This assumption is correct, but at the same time, the taglib-model is
nothing different from the clean-page model.
> We are not
> talking about simple pages here, but about sophisticated workflows. When
> I think of some of the hacks that have been reported on this list to
> make large sites work...
This is exactly the point: I understand you are working on this and you
rely on the technology for your job, believe me there is nobody on this
list that respect this more than I do... but do you want to continue
with these hacks forever?
There is a point where you need to cut the crap and do things with more
elegant design. Sure, this takes some time to get up to speed, like when
you learn a new programming language or a new technology, but if this
helps speeding you up in the future, this time is not wasted, is
invested.
Which is a big difference.
At the same time, we totally understand that C2 will be much different
from C1 so we'll make the path the smoother possible. This doesn't mean
there won't be bumps and back incompatibilities, there will be some, the
architecture is too different, but we'll make sure to ease this as much
as possible and we'll make C2 so irresistible that you'll feel ashamed
by still having to use C1 :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
RE: Aha! got it! 64k limit(was: new version of the sql
logicsheetunderdevelopment)
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 1 Sep 2000, Per Kreipke wrote:
> This might be a naiive observation (having only just realized that I can
> parse/style taglibs to make them documentable) it occurs to me that it
> might
> be possible to convert (or at least help) Cocoon1 XSP files to Cocoon2 by
> using Cocoon itself. E.g. extracting the <?cocoon-process?> processing
> instructions using XSLT (and possibly converting them to sitemap
> instructions?).
Whew, sounds like a hard job :) Think about dynamically generated PIs in
XSL stylesheets. You would have to really parse the stylesheets to see in
which cases which PIs are inserted.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
RE: Aha! got it! 64k limit(was: new version of the sql logicsheetunderdevelopment)
Posted by Per Kreipke <pe...@onclave.com>.
Uli, et al,
This might be a naiive observation (having only just realized that I can
parse/style taglibs to make them documentable) it occurs to me that it might
be possible to convert (or at least help) Cocoon1 XSP files to Cocoon2 by
using Cocoon itself. E.g. extracting the <?cocoon-process?> processing
instructions using XSLT (and possibly converting them to sitemap
instructions?).
Per.
> > From: Stefano Mazzocchi <st...@apache.org>
> >
> > Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be
> > hard to port, anything else will be piece of cake.
>
> Well, piece of cake or not, I have thousands of files, so I will need
> some time to port. Plus, the "hacks" I had to implement for processing
> chains should be put into the sitemap, this will also take some time.
> And I suspect the clean-page model will not work anymore in cocoon2, so
> everything needs to be converted over to the taglib-model. We are not
> talking about simple pages here, but about sophisticated workflows. When
> I think of some of the hacks that have been reported on this list to
> make large sites work...
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
RE: clean-page model (was: 64K Limit)
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 1 Sep 2000, Ed Staub wrote:
> What's the "clean-page" model? Does it mean scrupulously pushing logic
> back
> into taglibs?
No, that would be the taglib-model. Look at the clean-page.xml and
lib-page.xml in the xsp samples. Basically, they look like this:
clean-page:
<myfunctionality/>
lib-page:
<mytaglib:myfunctionality/>
I am not entirely sure which model is "better" or if that perhaps depends
on the scenario. The main difference is that the clean pages are pure XML,
whereas the lib pages are always XSP pages. So the lib-page model mixes
logic and content like in ASP or ColdFusion - but at least you have the
source (i.e. you write your own taglibs). The clean-page model is pure
content, functionality comes into it in its stylesheet, which can generate
a dynamic XSP page.
Now, the difference may be esoteric in the real world. After all, when you
look at the above examples it seems the only difference is in syntax. But
there are some subtle consequences stemming from the use of either model.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
RE: Aha! got it! 64k limit(was: new version of the sql logicsheetunderdevelopment)
Posted by Ed Staub <es...@mediaone.net>.
What's the "clean-page" model? Does it mean scrupulously pushing logic back
into taglibs?
-----------------------------
Sometimes you need to create structured data in an XSP's logic. What's the
recommended way to do that without using the DOM?
-----------------------------
I believe that we can reduce the code size of XSP pages by roughly 50% with
negligible (or maybe even positive) performance impact. It involves:
1.) Move the populateDocument() local stack variables (xspParentNode,
xspCurrentNode, xspNodeStack) and "document" argument into a
PopulatingContext object, which is probably a protected inner class of
XSPPage. This adds a lightweight object creation on each page create, but
I'm sure that this is insignificant in comparison to all the DOM object
creation going on within the page.
2.) Add final methods to PopulatingContext to encapsulate the following
fragments from xsp-java.xsl:
public final void StartElement(String elementName)
// replaces the following fragment (in <xsl:template match="*">):
// xspParentNode = xspCurrentNode;
// xspNodeStack.push(xspParentNode);
// xspCurrentNode =
// document.createElement("<xsl:value-of
select="name(.)"/>");
// xspParentNode.appendChild(xspCurrentNode);
{
xspParentNode = xspCurrentNode;
xspNodeStack.push(xspParentNode);
xspCurrentNode = document.createElement(elementName);
xspParentNode.appendChild(xspCurrentNode);
}
public final void CreateTextChild(String text)
// replaces the following fragment (in <xsl:template match="xsp:text">):
// xspCurrentNode.appendChild(
// document.createTextNode("<xsl:value-of select="."/>")
{ xspCurrentNode.appendChild(document.createTextNode(text));
}
3.) Change xsp-java.xsl:
a.) Use above "StartElement" method at start of <xsl:template match="*">.
b.) Remove normalize() at end of <xsl:template match="*">,
and put one normalize() at the end of the page. Since normalize() performs
a deep normalization, and there are no consumers of the XML before the
populateDocument() is completed, it should not be necessary to normalize
every element, and it causes an unnecessary full depth traversal of the DOM
from each element at the end of every element. Correct?
c.) Replace the code in <xsl:template match="xsp:text">
with a call to CreateTextChild() above.
d.) Change all other references to the populateDocument local variables
to access the PopulatingContext.
I don't know how serious folks are about the other possibilities which have
been floated. Some of them would make this enhancement irrelevant.
-Ed Staub
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: Friday, September 01, 2000 9:15 AM
To: cocoon-users@xml.apache.org
Subject: RE: Aha! got it! 64k limit(was: new version of the sql
logicsheetunderdevelopment)
> > Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be
> > hard to port, anything else will be piece of cake.
>
> Well, piece of cake or not, I have thousands of files, so I will need
> some time to port. Plus, the "hacks" I had to implement for processing
> chains should be put into the sitemap, this will also take some time.
> And I suspect the clean-page model will not work anymore in cocoon2, so
no clean-page model anymore... geez, I guess I'm getting in serious trouble
when I want upgrade to C2!
*sigh*
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: Aha! got it! 64k limit(was: new version of the sql logicsheetunderdevelopment)
Posted by Torsten Curdt <tc...@dff.st>.
> > Only XSP that used DOM directly (AND WE TOLD YOU NOT TO DO IT!) will be
> > hard to port, anything else will be piece of cake.
>
> Well, piece of cake or not, I have thousands of files, so I will need
> some time to port. Plus, the "hacks" I had to implement for processing
> chains should be put into the sitemap, this will also take some time.
> And I suspect the clean-page model will not work anymore in cocoon2, so
no clean-page model anymore... geez, I guess I'm getting in serious trouble
when I want upgrade to C2!
*sigh*
--
Torsten