You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.org> on 2003/07/30 18:52:34 UTC
logicsheet updated
I have fixed the logicsheet according to the changes within the
PageEnvelope API.
Please update your local CVS workspace. You also have to reset and
re-install.
ant reset (delete work)
ant install
Thanks
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> I think a logic sheet that simply invokes the page envelope input
>> module a couple of times would be fine with me.
>
> +1
+1 under the condition that we no longer access private data structures
from XSP.
>>> what's the problem with that? Transparency?
>>
>> It defines no clear interface.
> - it relies on implicit contracts (e.g., variable initialization)
> - you don't see the variable type
> - changing it's value could break the logicsheet
> - variable name clashes may occur
+1
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Christian Egli wrote:
>
> [...]
>
>> I think a logic sheet that simply invokes the page envelope input
>> module a couple of times would be fine with me.
>
>
> +1
>
> IMHO logicsheets should only simplify XSP development and should
> contain as little "knowledge" as possible, because they are very
> difficult to maintain (no IDE support).
+1
>
>>>> I'm against
>>>>
>>>> - accessing variables of the logicsheet from XSPs
>>>
>>>
>>> what's the problem with that? Transparency?
>>
>>
>> It defines no clear interface.
>
>
> - it relies on implicit contracts (e.g., variable initialization)
> - you don't see the variable type
> - changing it's value could break the logicsheet
> - variable name clashes may occur
>
> IMHO, logicsheets should only define local variables within
> template blocks:
>
> <xsl:template match="...">
> {
> int i = 0;
> }
> </xsl:template>
makes sense to me
>
>>>> - implicitely inserting XML fragments, Java code etc.
>>>
>>>
>>> AFAIK one cannot inherit XSPs, or am I wrong on this?
>>> What's the alternative?
>>
>>
>> I think the reason why Andreas doesn't want the logic sheet to insert
>> arbitrary Java code is to ensure that the stuff is handled where it
>> should be handled, i.e. in the Java code of the PageEnvelope,
>> Document, etc classes.
>
>
> Exactly (see above).
> With "implicitely" I mean that the tag name should show everything
> that is done by the tag, maybe it's better to call it "tags should
> have no side effects".
ok
Thanks
Michael
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Andreas Hartmann <an...@apache.org>.
Christian Egli wrote:
[...]
> I think a logic sheet that simply invokes the page envelope input
> module a couple of times would be fine with me.
+1
IMHO logicsheets should only simplify XSP development and should
contain as little "knowledge" as possible, because they are very
difficult to maintain (no IDE support).
>>>I'm against
>>>
>>>- accessing variables of the logicsheet from XSPs
>>
>>what's the problem with that? Transparency?
>
> It defines no clear interface.
- it relies on implicit contracts (e.g., variable initialization)
- you don't see the variable type
- changing it's value could break the logicsheet
- variable name clashes may occur
IMHO, logicsheets should only define local variables within
template blocks:
<xsl:template match="...">
{
int i = 0;
}
</xsl:template>
>>>- implicitely inserting XML fragments, Java code etc.
>>
>>AFAIK one cannot inherit XSPs, or am I wrong on this?
>>What's the alternative?
>
> I think the reason why Andreas doesn't want the logic sheet to insert
> arbitrary Java code is to ensure that the stuff is handled where it
> should be handled, i.e. in the Java code of the PageEnvelope,
> Document, etc classes.
Exactly (see above).
With "implicitely" I mean that the tag name should show everything
that is done by the tag, maybe it's better to call it "tags should
have no side effects".
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Christian Egli <ch...@wyona.com>.
Michael Wechner <mi...@wyona.org> writes:
> Andreas Hartmann wrote:
>
> > If we keep [the logic sheet] alive, we should agree on the purpose
> > of the logicsheet.
>
> The purpose of the logicsheet is to provide certain general
> parameters, such as for instance:
>
> - username
> - server time
> - area
> - document-url (authoring, live, etc.)
> - etc.
>
> without needing to specify them within the menu over and over again
That makes sense and was the original purpose of the logic sheet.
I think a logic sheet that simply invokes the page envelope input
module a couple of times would be fine with me.
> > This simplifies the usage, but adds another layer that has to be
> > maintained.
>
> no pain, no gain
I don't understand this. Why do want it to be more complicated? This
makes it harder for outside developers to get up to speed with the
system. If we add another layer that makes it simpler for the outside
developer then I would agree that it makes sense to maintain it.
> > I'm against
> >
> > - accessing variables of the logicsheet from XSPs
>
> what's the problem with that? Transparency?
It defines no clear interface.
> > - implicitely inserting XML fragments, Java code etc.
>
> AFAIK one cannot inherit XSPs, or am I wrong on this?
> What's the alternative?
I think the reason why Andreas doesn't want the logic sheet to insert
arbitrary Java code is to ensure that the stuff is handled where it
should be handled, i.e. in the Java code of the PageEnvelope,
Document, etc classes.
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Christian Egli wrote:
>
>> IMHO the logic sheet is in a pretty sad state and deserves to die. It
>> also opens up too much of the API towards the xsps. The input modules
>> offer a very clean way to access data for sitemap and xsps while
>> defining a clear interface (unlike the logic sheet (at least in it's
>> current state)).
>>
>
> If we keep it alive, we should agree on the purpose of the logicsheet.
The purpose of the logicsheet is to provide certain general parameters,
such as for instance:
- username
- server time
- area
- document-url (authoring, live, etc.)
- etc.
without needing to specify them within the menu over and over again
Please also see my email on the Page Envelope from 2003.7.7 (I can't
find it within gmane ...)
>
> I could imagine an API simplification for the page envelope:
>
> - <lenya:document-id/> instead of the page envelope call -
that would certainly help, but you would still need to specify all the
parameters from above
for each menu.
>
>
> This simplifies the usage, but adds another layer that has to be
> maintained.
no pain, no gain
>
>
> I'm against
>
> - accessing variables of the logicsheet from XSPs
what's the problem with that? Transparency?
>
> - tags with too general names, like <xsp-lenya:util/>
agreed, but it grew historically and needs some refactoring
>
> - implicitely inserting XML fragments, Java code etc.
AFAIK one cannot inherit XSPs, or am I wrong on this?
What's the alternative?
Thanks
Michael
>
>
> What do you think?
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> - accessing variables of the logicsheet from XSPs
> - tags with too general names, like <xsp-lenya:util/>
> - implicitely inserting XML fragments, Java code etc.
im with you on this
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Andreas Hartmann <an...@apache.org>.
Christian Egli wrote:
> IMHO the logic sheet is in a pretty sad state and deserves to die. It
> also opens up too much of the API towards the xsps. The input modules
> offer a very clean way to access data for sitemap and xsps while
> defining a clear interface (unlike the logic sheet (at least in it's
> current state)).
>
If we keep it alive, we should agree on the purpose of the logicsheet.
I could imagine an API simplification for the page envelope:
- <lenya:document-id/> instead of the page envelope call -
This simplifies the usage, but adds another layer that has to be
maintained.
I'm against
- accessing variables of the logicsheet from XSPs
- tags with too general names, like <xsp-lenya:util/>
- implicitely inserting XML fragments, Java code etc.
What do you think?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Christian Egli wrote:
> IMHO the logic sheet is in a pretty sad state and deserves to die.
+1
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Christian Egli <ch...@wyona.com>.
Michael Wechner <mi...@wyona.org> writes:
> Christian Egli wrote:
>
> >IMHO the logic sheet is in a pretty sad state and deserves to die.
>
> what exactly do you mean by sad state?
Everytime we change something we can be sure that the util.xsl will
break because it was not from the start to be as robust as the
PageEnvelope (e.g. it often has problems when invoked from a global
sitemap).
Also it carries a lot of cruft that should die but we're to scared to
delete it, 'cause something migth still use it.
This comes back to the problem of not having a clear interface
(everything is used from outside, even java variables), so we cannot
even deprecate parts of the interface because we don't know what the
interface is.
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Michael Wechner <mi...@wyona.org>.
Christian Egli wrote:
>
>IMHO the logic sheet is in a pretty sad state and deserves to die.
>
what exactly do you mean by sad state?
Thanks
Michael
> It
>also opens up too much of the API towards the xsps. The input modules
>offer a very clean way to access data for sitemap and xsps while
>defining a clear interface (unlike the logic sheet (at least in it's
>current state)).
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: logicsheet updated
Posted by Christian Egli <ch...@wyona.com>.
Michael Wechner <mi...@wyona.org> writes:
> I have fixed the logicsheet according to the changes within the
> PageEnvelope API.
Are you talking about the util.xsl logicsheet?
If yes we should probably discuss the strategy how we are going to
move forward with this logic sheet. As I was reading through the
commit messages it seems that we do not work from the same
assumptions. Andreas was getting rid of the logic sheet in one xsp
while you were adding it to another xsp.
IMHO the logic sheet is in a pretty sad state and deserves to die. It
also opens up too much of the API towards the xsps. The input modules
offer a very clean way to access data for sitemap and xsps while
defining a clear interface (unlike the logic sheet (at least in it's
current state)).
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org