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.com> on 2005/07/10 23:33:51 UTC
introduction of lenya-core protocol
Hi
In order to be able to do real publets, which can be plugged in
at any place, I think it would make sense to introduce the lenya-core
protocol, e.g.
<map:transform src="lenya-core://xslt/util/strip_namespaces.xsl"/>
instead of
<map:transform src="../../xslt/util/strip_namespaces.xsl"/>
WDYT?
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> org.apache.forrest.locationmap.*
>
> I am on my way out. I do not know whether it is only accessible as an
> InputModule.
Thanks, I'll take a look into that.
[...]
> hmm, adding complexity? I reckon it is doing the opposite. I would
> recommend to have it in the core and each pub can have their own
> overriding map.
>
> ...and using existing technology is IMO better to invent lenya specific
> protocols.
>
> The last point is that our 'configuration' is hell complicated and the
> locationmap seems to help solving some aspects.
I don't see how this reduces configuration complexity ...
At the moment, all you configure is the template in publication.xconf.
[...]
>>Another point: How would loops be implemented?
>>You have a chain of parents. Is it possible to use recursion?
>>
>
>
> The example has a loop.
>>> <select type="exists">
>>> <location src="pub/..." />
>>> <location src="parent/" />
>>> <location src="context://lenya/...">
>>> </select>
Does <location src="parent/" /> send another call into the location map,
i.e. does this pipeline recurse?
>>BTW, what I don't yet see is how this replaces the parent:// protocol?
>>
>
> Then please explain again what parent:// should do. Maybe I
> misunderstood it.
The parent:// protocol should do the same as fallback://, but it should
skip the current publication when looking for a resource.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-14 at 18:07 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
>
> [...]
>
> > should become
> > <map:read src="{lm:resources/shared/css/{3}.css}"
>
> How would that be used from Java classes?
>
> Like I would use sourceResolver.resolveURI("fallback://..."),
> is there a Java API for LocationMaps, or is it accessible as an
> InputModule only?
>
org.apache.forrest.locationmap.*
I am on my way out. I do not know whether it is only accessible as an
InputModule.
>
> > mime-type="text/css" />
> >
> > Then you can have in your locationmap:
> > <match pattern="resources/**.css" type="request">
> > <select type="exists">
> > <location src="pub/..." />
> > <location src="parent/" />
> > <location src="context://lenya/...">
> > </select>
> > <location src="fallback://resources..." />
> > </match>
> >
> > This way each pub can define their own fallback mechanism *without* inventing new protocols all the time.
>
> IMO that's just another configuration of the publication template.
> A benefit is that we would use existing technology to implement
> fallback, but it adds complexity to the configuration.
>
hmm, adding complexity? I reckon it is doing the opposite. I would
recommend to have it in the core and each pub can have their own
overriding map.
...and using existing technology is IMO better to invent lenya specific
protocols.
The last point is that our 'configuration' is hell complicated and the
locationmap seems to help solving some aspects.
> But there is a major problem:
>
> Publication templating is an abstract concept which is an integral
> part of Lenya. The fallback mechanism for files is just one aspect.
> We need a central configuration point for a template (which cannot
> be a location map), otherwise we'll run into trouble.
>
I need to get into publication templating before I can say something to
it.
> Another point: How would loops be implemented?
> You have a chain of parents. Is it possible to use recursion?
>
The example has a loop.
> ----
>
> BTW, what I don't yet see is how this replaces the parent:// protocol?
>
Then please explain again what parent:// should do. Maybe I
misunderstood it.
> Thanks for the example,
>
de nada.
salu2
> -- Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
> should become
> <map:read src="{lm:resources/shared/css/{3}.css}"
How would that be used from Java classes?
Like I would use sourceResolver.resolveURI("fallback://..."),
is there a Java API for LocationMaps, or is it accessible as an
InputModule only?
> mime-type="text/css" />
>
> Then you can have in your locationmap:
> <match pattern="resources/**.css" type="request">
> <select type="exists">
> <location src="pub/..." />
> <location src="parent/" />
> <location src="context://lenya/...">
> </select>
> <location src="fallback://resources..." />
> </match>
>
> This way each pub can define their own fallback mechanism *without* inventing new protocols all the time.
IMO that's just another configuration of the publication template.
A benefit is that we would use existing technology to implement
fallback, but it adds complexity to the configuration.
But there is a major problem:
Publication templating is an abstract concept which is an integral
part of Lenya. The fallback mechanism for files is just one aspect.
We need a central configuration point for a template (which cannot
be a location map), otherwise we'll run into trouble.
Another point: How would loops be implemented?
You have a chain of parents. Is it possible to use recursion?
----
BTW, what I don't yet see is how this replaces the parent:// protocol?
Thanks for the example,
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-14 at 11:57 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
> > It seems to me that me may consider using a locationmap for the below
> > stated example and not another protocol.
> >
> > http://marc.theaimsgroup.com/?l=forrest-dev&m=110656404918792&w=2
>
> Would you mind describing the usage of a location map in this context
> in more detail? I've read the proposal / description, but I'm not quite
> sure how this relates to our problem. Maybe you can provide an example?
>
> Thanks!
e.g.
> >>>example 2 (xhtml.css and resources-shared.xmap):
> >>>
> >>> xhtml.css:
> >>>
> >>>@import url(xhtml.parent.css);
> >>
> >> >
> >>
> >>>body {
> >>> margin: 0px;
> >>> padding: 0px;
> >>> background: #F6D897;
> >>> font-size: 90%;
> >>>}
> >>>
> >>> resources-shared.xmap:
> >>> <map:match pattern="*/*/css/*.parent.css">
> >>> <map:read src="parent://resources/shared/css/{3}.css"
> >>>mime-type="text/css" />
> >>> </map:match>
> >>
should become
<map:read src="{lm:resources/shared/css/{3}.css}"
mime-type="text/css" />
Then you can have in your locationmap:
<match pattern="resources/**.css" type="request">
<select type="exists">
<location src="pub/..." />
<location src="parent/" />
<location src="context://lenya/...">
</select>
<location src="fallback://resources..." />
</match>
This way each pub can define their own fallback mechanism *without* inventing new protocols all the time.
What happen here is that the first existing location will be taken till it reaches the last <location/> (outside the <select/>).
This last location should be ideally always be found. ;-)
The nice thing is that it can be combined with the fallback mechanism or other protocols.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> It seems to me that me may consider using a locationmap for the below
> stated example and not another protocol.
>
> http://marc.theaimsgroup.com/?l=forrest-dev&m=110656404918792&w=2
Would you mind describing the usage of a location map in this context
in more detail? I've read the proposal / description, but I'm not quite
sure how this relates to our problem. Maybe you can provide an example?
Thanks!
-- Andreas
> We are implementing it ATM over in forrest and it is pretty need. I also
> installed the locationmap once in 1.2.x in a customer project. It is
> working very nice.
>
> salu2
> thorsten
>
> On Thu, 2005-07-14 at 09:58 +0200, Andreas Hartmann wrote:
>
>>Doug Chestnut wrote:
>>
>>>Playing around with Publication Templates, I have found that it would be
>>>really nice to have something like a parent:// | ancestor:// |
>>>fallbackfromparent:// protocol. It would do something like this:
>>>
>>>1. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
>>>2. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
>>>3. ...
>>>4. context://xslt/page2xhtml.xsl
>>
>>Actually I had the same in mind :)
>>
>><quote
>>src="http://lenya.apache.org/1_4/reference/publication-templating/index.html">
>> To simplify overriding of XSLT stylesheets, it would be useful to import
>> the template stylesheet. For this purpose, an additional template source
>> factory could be used, which skips the current publication when resolving
>> the file:
>>
>> <xsl:import href="template://template/xslt/common/header.xsl"/>
>></quote>
>>
>>
>>[...]
>>
>>
>>><xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
>>
>>That would certainly make sense.
>>
>>I've read Gregor's suggestion on expanding variables, I'm not sure which
>>approach to prefer.
>>
>>
>>
>>>example 2 (xhtml.css and resources-shared.xmap):
>>>
>>> xhtml.css:
>>>
>>>@import url(xhtml.parent.css);
>>
>> >
>>
>>>body {
>>> margin: 0px;
>>> padding: 0px;
>>> background: #F6D897;
>>> font-size: 90%;
>>>}
>>>
>>> resources-shared.xmap:
>>> <map:match pattern="*/*/css/*.parent.css">
>>> <map:read src="parent://resources/shared/css/{3}.css"
>>>mime-type="text/css" />
>>> </map:match>
>>
>>That looks very nice!
>>
>>-- Andreas
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>For additional commands, e-mail: dev-help@lenya.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Thorsten Scherler <th...@apache.org>.
It seems to me that me may consider using a locationmap for the below
stated example and not another protocol.
http://marc.theaimsgroup.com/?l=forrest-dev&m=110656404918792&w=2
We are implementing it ATM over in forrest and it is pretty need. I also
installed the locationmap once in 1.2.x in a customer project. It is
working very nice.
salu2
thorsten
On Thu, 2005-07-14 at 09:58 +0200, Andreas Hartmann wrote:
> Doug Chestnut wrote:
> > Playing around with Publication Templates, I have found that it would be
> > really nice to have something like a parent:// | ancestor:// |
> > fallbackfromparent:// protocol. It would do something like this:
> >
> > 1. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
> > 2. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
> > 3. ...
> > 4. context://xslt/page2xhtml.xsl
>
> Actually I had the same in mind :)
>
> <quote
> src="http://lenya.apache.org/1_4/reference/publication-templating/index.html">
> To simplify overriding of XSLT stylesheets, it would be useful to import
> the template stylesheet. For this purpose, an additional template source
> factory could be used, which skips the current publication when resolving
> the file:
>
> <xsl:import href="template://template/xslt/common/header.xsl"/>
> </quote>
>
>
> [...]
>
> > <xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
>
> That would certainly make sense.
>
> I've read Gregor's suggestion on expanding variables, I'm not sure which
> approach to prefer.
>
>
> > example 2 (xhtml.css and resources-shared.xmap):
> >
> > xhtml.css:
> >
> > @import url(xhtml.parent.css);
> >
> > body {
> > margin: 0px;
> > padding: 0px;
> > background: #F6D897;
> > font-size: 90%;
> > }
> >
> > resources-shared.xmap:
> > <map:match pattern="*/*/css/*.parent.css">
> > <map:read src="parent://resources/shared/css/{3}.css"
> > mime-type="text/css" />
> > </map:match>
>
> That looks very nice!
>
> -- Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
> Playing around with Publication Templates, I have found that it would be
> really nice to have something like a parent:// | ancestor:// |
> fallbackfromparent:// protocol. It would do something like this:
>
> 1. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
> 2. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
> 3. ...
> 4. context://xslt/page2xhtml.xsl
Actually I had the same in mind :)
<quote
src="http://lenya.apache.org/1_4/reference/publication-templating/index.html">
To simplify overriding of XSLT stylesheets, it would be useful to import
the template stylesheet. For this purpose, an additional template source
factory could be used, which skips the current publication when resolving
the file:
<xsl:import href="template://template/xslt/common/header.xsl"/>
</quote>
[...]
> <xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
That would certainly make sense.
I've read Gregor's suggestion on expanding variables, I'm not sure which
approach to prefer.
> example 2 (xhtml.css and resources-shared.xmap):
>
> xhtml.css:
>
> @import url(xhtml.parent.css);
>
> body {
> margin: 0px;
> padding: 0px;
> background: #F6D897;
> font-size: 90%;
> }
>
> resources-shared.xmap:
> <map:match pattern="*/*/css/*.parent.css">
> <map:read src="parent://resources/shared/css/{3}.css"
> mime-type="text/css" />
> </map:match>
That looks very nice!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Doug Chestnut wrote:
>> <xsl:import href="fallback://{parent}xslt/page2xhtml-xhtml.xsl">
>
> Ok, this was what I was looking for. However this doesn't work :). I
yeah, it was an example. several protocols have support for such
variable expansion. in this case, {parent} would expand to the parent
publication by convention.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Doug Chestnut <ch...@apache.org>.
Gregor J. Rothfuss wrote:
> Doug Chestnut wrote:
>
>> <xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
>
>
>> Am I missing something, would there be a better way of doing something
>> like this? Figured that I would join in on the protocol free for all :).
>
>
> yes:
>
> <xsl:import href="fallback://{parent}xslt/page2xhtml-xhtml.xsl">
Ok, this was what I was looking for. However this doesn't work :). I
guess that I need to make the parent variable in my sitemap. What
should the parent variable be? I tried replacing {parent} with
parentTemplateName/ in my sitemap but that didn't work.
I am guessing this is functionality that would need to be added to the
fallback input module? I could use context:/ but that doesn't have the
same strength as "fallback from parent".
Using
"fallback://lenya/pubs/parentTemplateName/resources/shared/css/{3}.css"
works, but seems to be no different from context:// as it doesn't look
at the parent templates of parentTemplateName.
"fallback://parentTemplateName/resources/shared/css/{3}.css" doesn't work:
org.apache.excalibur.source.SourceNotFoundException:
file:/C:/src/lenya-1.4.x.WEBDAV/build/lenya/webapp/parentTemplateName/resources/shared/css/default.css
doesn't exist.
"fallback://{parent}resources/shared/css/{3}.css" gives me the same
result as "fallback://resources/shared/css/{3}.css".
>
> we should avoid gratuitous protocols that have only subtly different
> semantics
Agreed.
So, my guess is that this is a stab at how it should work (fallback
input module should be able to handle this):
<xsl:import href="fallback://{parent}xslt/page2xhtml-xhtml.xsl">
What should the value of {parent} be?
parentTemplateName/
lenya/pubs/parentTemplateName/ (I am thinking this one)
I will take a closer look at FallbackModule.java ;)
Thanks,
--Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Doug Chestnut wrote:
> <xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
> Am I missing something, would there be a better way of doing something
> like this? Figured that I would join in on the protocol free for all :).
yes:
<xsl:import href="fallback://{parent}xslt/page2xhtml-xhtml.xsl">
we should avoid gratuitous protocols that have only subtly different
semantics
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Doug Chestnut <ch...@apache.org>.
Playing around with Publication Templates, I have found that it would be
really nice to have something like a parent:// | ancestor:// |
fallbackfromparent:// protocol. It would do something like this:
1. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
2. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
3. ...
4. context://xslt/page2xhtml.xsl
With something like this I could have a tree of publications
(http://lenya.apache.org/1_4/reference/publication-templating/index.html)
and pubs using templates could extend the css, xslt, etc from the
parent instead of completely rewriting it.
example 1 (page2xhtml-xhtml.xsl):
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xsl:import href="parent://xslt/page2xhtml-xhtml.xsl"/>
<xsl:template match="xhtml:font">
<xhtml:strong>No font elements allowed in this publication, use css
instead</xhtml:strong>
<xsl:apply-templates select="*"/>
</xsl:template>
</xsl:stylesheet>
example 2 (xhtml.css and resources-shared.xmap):
xhtml.css:
@import url(xhtml.parent.css);
body {
margin: 0px;
padding: 0px;
background: #F6D897;
font-size: 90%;
}
resources-shared.xmap:
<map:match pattern="*/*/css/*.parent.css">
<map:read src="parent://resources/shared/css/{3}.css"
mime-type="text/css" />
</map:match>
Am I missing something, would there be a better way of doing something
like this? Figured that I would join in on the protocol free for all :).
--Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-07-12 at 09:51 +0200, Andreas Hartmann wrote:
> Doug Chestnut wrote:
> > Michael Wechner wrote:
> >
> >> sure we could use fallback:// or context:// but it seems to me naming
> >> is very important. For instance what does fallback mean? Fallback
> >> to the parent publication, to the core, ...?
> >
> > fallback to the parent pub, if resource isn't present there, fallback to
> > its parent pub, ..., fallback to the lenya core (as I understand how
> > it's supposed to work).
>
> Yes:
>
> <quote>
>
> When a file is requested using the templating mechanism
> (fallback://xslt/page2xhtml.xsl), it is searched in a certain traversing order:
>
> 1. context://lenya/pubs/my-pub/xslt/page2xhtml.xsl
> 2. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
> 3. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
> 4. ...
> 5. context://xslt/page2xhtml.xsl
>
> </quote>
>
> (http://lenya.apache.org/1_4/reference/publication-templating/index.html)
>
>
> >
> >>
> >> So I think for instance
> >>
> >> lenya-core-fallback://
> >>
> >> or lenya-core://
> >
> > I do like the name lenya-core better than context. I have never used
> > context:// and didn't have a clue of what it did (never looked in the
> > documentation for it),
>
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/source/impl/ContextSourceFactory.html
>
> Not that much either ... :)
>
> > but lenya-core:// might be a little more self
> > explanatory ;).
>
> OK, that's true.
I would change my mind if we can access with lenya-core:// as well lenya
core java resources://. Then this makes sense for me.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
> Michael Wechner wrote:
>
>> sure we could use fallback:// or context:// but it seems to me naming
>> is very important. For instance what does fallback mean? Fallback
>> to the parent publication, to the core, ...?
>
> fallback to the parent pub, if resource isn't present there, fallback to
> its parent pub, ..., fallback to the lenya core (as I understand how
> it's supposed to work).
Yes:
<quote>
When a file is requested using the templating mechanism
(fallback://xslt/page2xhtml.xsl), it is searched in a certain traversing order:
1. context://lenya/pubs/my-pub/xslt/page2xhtml.xsl
2. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
3. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
4. ...
5. context://xslt/page2xhtml.xsl
</quote>
(http://lenya.apache.org/1_4/reference/publication-templating/index.html)
>
>>
>> So I think for instance
>>
>> lenya-core-fallback://
>>
>> or lenya-core://
>
> I do like the name lenya-core better than context. I have never used
> context:// and didn't have a clue of what it did (never looked in the
> documentation for it),
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/source/impl/ContextSourceFactory.html
Not that much either ... :)
> but lenya-core:// might be a little more self
> explanatory ;).
OK, that's true.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Doug Chestnut <ch...@apache.org>.
Michael Wechner wrote:
> sure we could use fallback:// or context:// but it seems to me naming
> is very important. For instance what does fallback mean? Fallback
> to the parent publication, to the core, ...?
fallback to the parent pub, if resource isn't present there, fallback to
its parent pub, ..., fallback to the lenya core (as I understand how
it's supposed to work).
>
> So I think for instance
>
> lenya-core-fallback://
>
> or lenya-core://
I do like the name lenya-core better than context. I have never used
context:// and didn't have a clue of what it did (never looked in the
documentation for it), but lenya-core:// might be a little more self
explanatory ;).
--Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
>>
>> yes, but by using lenya-core we could remove the lenya prefix,
>>
>> lenya-core://xslt/util/strip_namespaces.xsl
>
>
> OK, but is this worth another protocol?
well, I think it makes it very clear what comes from the core
and what is actually the core
> I don't mind introducing the core protocol, as long as it provides
> additional value. Up to now, I'm +-0 ...
sure we could use fallback:// or context:// but it seems to me naming
is very important. For instance what does fallback mean? Fallback
to the parent publication, to the core, ...?
So I think for instance
lenya-core-fallback://
or lenya-core://
makes that much clearer.
Michi
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> Anyway coming back to the lenya-core: protocol I agree with andreas I do
> not see much value added by it.
-1 for lenya-core
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-07-11 at 12:02 +0200, Andreas Hartmann wrote:
> Michael Wechner wrote:
> > Andreas Hartmann wrote:
> >
> >> Michael Wechner wrote:
> >>
> >>> Hi
> >>>
> >>> In order to be able to do real publets, which can be plugged in
> >>> at any place, I think it would make sense to introduce the lenya-core
> >>> protocol, e.g.
> >>>
> >>> <map:transform src="lenya-core://xslt/util/strip_namespaces.xsl"/>
> >>>
> >>> instead of
> >>>
> >>> <map:transform src="../../xslt/util/strip_namespaces.xsl"/>
> >>>
> >>> WDYT?
> >>
> >>
I agree that we have to get rid of the "../../" src calls because they
prevent not only publets but as well that lenya will become copyless.
Copyless (for jetty) means I do not need to rebuild lenya if I change
something in the src, because the build is actually using the src files.
Java classes and changes of *.xconf files will still need a build (or
restart) that is true.
Anyway coming back to the lenya-core: protocol I agree with andreas I do
not see much value added by it.
+-0
salu2
> >>
> >> In most cases that should be done using the fallback protocol:
> >>
> >> <map:transform src="fallback://lenya/xslt/util/strip_namespaces.xsl"/>
> >
> >
> >
> > what about performance? I guess the fallback needs to check on the file?
>
> I wouldn't assume a measurable performance decrease without profiling.
> When the source validitiy is checked, the file is being looked at anyway ...
>
>
> > Or is t
> >
> >>
> >> Maybe there are a few cases where fallback is not desired, then
> >> the lenya-core protocol makes sense. A special case is including
> >> the core stylesheet from a derived stylesheet.
> >>
> >> We could actually use the ContextSourceFactory for that purpose,
> >> since it would use the same syntax:
> >>
> >> <map:transform src="lenya-core://lenya/xslt/util/strip_namespaces.xsl"/>
> >>
> >> is the same as
> >>
> >> <map:transform src="context://lenya/xslt/util/strip_namespaces.xsl"/>
> >
> >
> >
> > yes, but by using lenya-core we could remove the lenya prefix,
> >
> > lenya-core://xslt/util/strip_namespaces.xsl
>
> OK, but is this worth another protocol?
> I don't mind introducing the core protocol, as long as it provides
> additional value. Up to now, I'm +-0 ...
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Michael Wechner wrote:
>>
>>> Hi
>>>
>>> In order to be able to do real publets, which can be plugged in
>>> at any place, I think it would make sense to introduce the lenya-core
>>> protocol, e.g.
>>>
>>> <map:transform src="lenya-core://xslt/util/strip_namespaces.xsl"/>
>>>
>>> instead of
>>>
>>> <map:transform src="../../xslt/util/strip_namespaces.xsl"/>
>>>
>>> WDYT?
>>
>>
>>
>> In most cases that should be done using the fallback protocol:
>>
>> <map:transform src="fallback://lenya/xslt/util/strip_namespaces.xsl"/>
>
>
>
> what about performance? I guess the fallback needs to check on the file?
I wouldn't assume a measurable performance decrease without profiling.
When the source validitiy is checked, the file is being looked at anyway ...
> Or is t
>
>>
>> Maybe there are a few cases where fallback is not desired, then
>> the lenya-core protocol makes sense. A special case is including
>> the core stylesheet from a derived stylesheet.
>>
>> We could actually use the ContextSourceFactory for that purpose,
>> since it would use the same syntax:
>>
>> <map:transform src="lenya-core://lenya/xslt/util/strip_namespaces.xsl"/>
>>
>> is the same as
>>
>> <map:transform src="context://lenya/xslt/util/strip_namespaces.xsl"/>
>
>
>
> yes, but by using lenya-core we could remove the lenya prefix,
>
> lenya-core://xslt/util/strip_namespaces.xsl
OK, but is this worth another protocol?
I don't mind introducing the core protocol, as long as it provides
additional value. Up to now, I'm +-0 ...
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Hi
>>
>> In order to be able to do real publets, which can be plugged in
>> at any place, I think it would make sense to introduce the lenya-core
>> protocol, e.g.
>>
>> <map:transform src="lenya-core://xslt/util/strip_namespaces.xsl"/>
>>
>> instead of
>>
>> <map:transform src="../../xslt/util/strip_namespaces.xsl"/>
>>
>> WDYT?
>
>
> In most cases that should be done using the fallback protocol:
>
> <map:transform src="fallback://lenya/xslt/util/strip_namespaces.xsl"/>
what about performance? I guess the fallback needs to check on the file?
Or is t
>
> Maybe there are a few cases where fallback is not desired, then
> the lenya-core protocol makes sense. A special case is including
> the core stylesheet from a derived stylesheet.
>
> We could actually use the ContextSourceFactory for that purpose,
> since it would use the same syntax:
>
> <map:transform src="lenya-core://lenya/xslt/util/strip_namespaces.xsl"/>
>
> is the same as
>
> <map:transform src="context://lenya/xslt/util/strip_namespaces.xsl"/>
yes, but by using lenya-core we could remove the lenya prefix,
lenya-core://xslt/util/strip_namespaces.xsl
Michi
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: introduction of lenya-core protocol
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Hi
>
> In order to be able to do real publets, which can be plugged in
> at any place, I think it would make sense to introduce the lenya-core
> protocol, e.g.
>
> <map:transform src="lenya-core://xslt/util/strip_namespaces.xsl"/>
>
> instead of
>
> <map:transform src="../../xslt/util/strip_namespaces.xsl"/>
>
> WDYT?
In most cases that should be done using the fallback protocol:
<map:transform src="fallback://lenya/xslt/util/strip_namespaces.xsl"/>
Maybe there are a few cases where fallback is not desired, then
the lenya-core protocol makes sense. A special case is including
the core stylesheet from a derived stylesheet.
We could actually use the ContextSourceFactory for that purpose,
since it would use the same syntax:
<map:transform src="lenya-core://lenya/xslt/util/strip_namespaces.xsl"/>
is the same as
<map:transform src="context://lenya/xslt/util/strip_namespaces.xsl"/>
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org