You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Rolf Kulemann <ma...@rolf-kulemann.com> on 2003/12/14 14:58:11 UTC
Re: Epoz integration patches pending...
On Sat, 2003-12-13 at 11:08, Rolf Kulemann wrote:
> > > very cool :-) If you send the patches, then I can review and apply them.
>
> Now, css works for file being edited.
> I have attached a new set of patched files. Completey forget the old
> sent files.
>
> Have fun and Enjoy XHTML wysiwyg editing with Epoz.
>
>
> Many thanks to the Epoz community for that great tool.
>
> TODO:
>
> - Rewrite css files used by Epoz in an xslt. Implement that with
> fallback functionality, in order to get different Epoz L&F per pub.
Now each pub can override the epoz css and screen generation. I used the
FallbackModule, which is quite comfortable. One problem with that module
might be, that one can't use it for a *client side* fallback i.e. when
requesting a .css file. The FallbackModule is not taking care of paths
like resources/css/mystyle.css. The requested URI in this case has to be
css/mystyle.css therefor the FallbackModule should return
css/mystyle.css or pub/css/mystyle.css.
However here are the patched and added files again (ZIP):
lenya/lenya/usecase.xmap
lenya/lenya/resouces/misc/epoz/epozmacros.html
lenya/lenya/xslt/authoring/edit/epoz/epozcontent-xhtml.xsl
lenya/lenya/xslt/authoring/edit/epoz/epozsave-xhtml.xsl
lenya/lenya/xslt/authoring/edit/epoz/epozmacros-xhtml.xsl
lenya/lenya/resources/css/epozcustom.css
and in publication space:
lenya/default/lenyaxslt/authoring/edit/epoz/epozmacros-xhtml.xsl
lenya/default/resources/css/epozcustom.css
Also attached is a screenshot of the Epoz edit screen, so that the
interested can get an impression, but note: I'm no artist. May someone
else contribute an *ass kickin'* css :)
I hope this gets comitted soon :)
ToDo:
- Do some css classes for table layouts like predefined by Epoz.
--
Rolf Kulemann
Finagle's First Law:
If an experiment works, something has gone wrong.
PGP/GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6B4EA7EA
Re: Epoz integration patches pending...
Posted by Rolf Kulemann <ma...@rolf-kulemann.com>.
On Wed, 2003-12-17 at 11:43, Jann Forrer wrote:
> On Tue, 16 Dec 2003, Rolf Kulemann wrote:
>
> [...]
> I didnt understand the whole thread!
I'm very sorry for my really bad english! Lets try again.
> Therefoe I have a, probably stupid,
> question. The fallback
>
> {fallback:/css/myfile.css}
>
> would return "/lenya/css/myfile.css" or "/lenya/[pub]/css/myfile.css".
> Why do you want to use {fallback:/link/css/myfile.css} instead?
That was only one suggestion to indicate the FallbackModule that I use
the path for the *outside of lenya world*. Should mean :/link/...
indicates to prepare the returned path for use in a link tag for
example. But as I said, I prefer the following solution:
>
> > Another solution could be to define another input module which is just a
> > special FallbackModule configuration like it is done with the
> > linkrewriter(ext:, site:, etc.) in Forrest. So you can use
> > {resource:resources/css/myfile.css} !!corrected!!
which returns lenya/css/myfile.css or lenya/[pub]/css/myfile.css,
but not lenya/resources/css/myfile.css or
lenya/[pub]/resources/css/myfile.css, because this would not work.
Another Idea is to change the matchers in appropiate pipelines.
> > [...]
Is there somebody out there who understands what I mean?
--
</RolfKulemann>
Always remember:
"There is inherently no silver bullet." - F.Brooks
PGP/GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6B4EA7EA
Re: Epoz integration patches pending...
Posted by Jann Forrer <ja...@id.unizh.ch>.
On Tue, 16 Dec 2003, Rolf Kulemann wrote:
[...]
>
> I use a <link ...> tag to define a stylesheet in an html/xml page send
> to a browser. I want to check if a stylesheet ios available in pub space
> and if so I use that one.
>
> The problem is I cant use the path returned by the fallback module as
> is.
>
> So I started thinking of a general solution for that problem. Of course
> I do not want to break contracts.
>
> Here is another thought:
>
> What do you think of scheming the fallback module like:
>
> {fallback:/link/css/myfile.css}
>
> which returns "/lenya/css/myfile.css" or "/lenya/[pub]/css/myfile.css"
>
I didnt understand the whole thread! Therefoe I have a, probably stupid,
question. The fallback
{fallback:/css/myfile.css}
would return "/lenya/css/myfile.css" or "/lenya/[pub]/css/myfile.css".
Why do you want to use {fallback:/link/css/myfile.css} instead?
> Another solution could be to define another input module which is just a
> special FallbackModule configuration like it is done with the
> linkrewriter(ext:, site:, etc.) in Forrest. So you can use
> {resource:css/myfile.css}
>
Would that mean that you similar functionality as defined in the
fallback module:
lenya/[pub]/lenya/xslt/xy --> lenya/xslt/xy)
but for the resources e.g.
lenya/[pub]/resources/css/myfile.css --> lenya/resources/css/myfile.css ?
>
> I could also image to solve that prob with an action simliar to what
> Jann did. An action my case is not that comfortable. I would prefer the
> configuration of the FallbackModule.
>
I had the Problem that sitemap parameters can not be nested in module
calls as e.g.
<map:read src="{unizh:root-pub/resources/{1}.gif}"
Jann
---------------------------------------------------------------
Jann Forrer
Informatikdienste
Universität Zürich
Winterthurerstr. 190
CH-8057 Zuerich
oooO mail: jann.forrer@id.unizh.ch
( ) phone: +41 1 63 56772
\ ( fax: +41 1 63 54505
\_) http://www.id.unizh.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Rolf Kulemann <ma...@rolf-kulemann.com>.
On Mon, 2003-12-15 at 11:16, Andreas Hartmann wrote:
> Rolf Kulemann wrote:
>
> [...]
> >
> > I could imagine an overriding function for files requested by the client
> > i.e. a web browser.
> >
> > With the FallbackModule I can i.e. check for resources/css/style.css,
> > but I can't send the path returned by the client for insertion in a html
> > file or so, because it must remove the "resources" part of the path.
>
> OK, now I see what you mean.
>
> > Client needs to request the css via /lenya/default/live/css/style.css,
> > thus the path returned by the FallbackModule is not the path to be used
> > in a <link> tag.
>
> Why do you want to use a path which is returned by the
> fallback module inside a link? The fallback module supports
> mapping a requested URL (which is always the same) to
> different files ...
I use a <link ...> tag to define a stylesheet in an html/xml page send
to a browser. I want to check if a stylesheet ios available in pub space
and if so I use that one.
The problem is I cant use the path returned by the fallback module as
is.
So I started thinking of a general solution for that problem. Of course
I do not want to break contracts.
Here is another thought:
What do you think of scheming the fallback module like:
{fallback:/link/css/myfile.css}
which returns "/lenya/css/myfile.css" or "/lenya/[pub]/css/myfile.css"
Another solution could be to define another input module which is just a
special FallbackModule configuration like it is done with the
linkrewriter(ext:, site:, etc.) in Forrest. So you can use
{resource:css/myfile.css}
I could also image to solve that prob with an action simliar to what
Jann did. An action my case is not that comfortable. I would prefer the
configuration of the FallbackModule.
Comments are welcome.
--
Rolf Kulemann
All I ask of life is a constant and exaggerated sense of my own
importance.
PGP/GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6B4EA7EA
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Andreas Hartmann <an...@apache.org>.
Rolf Kulemann wrote:
[...]
>
> I could imagine an overriding function for files requested by the client
> i.e. a web browser.
>
> With the FallbackModule I can i.e. check for resources/css/style.css,
> but I can't send the path returned by the client for insertion in a html
> file or so, because it must remove the "resources" part of the path.
OK, now I see what you mean.
> Client needs to request the css via /lenya/default/live/css/style.css,
> thus the path returned by the FallbackModule is not the path to be used
> in a <link> tag.
Why do you want to use a path which is returned by the
fallback module inside a link? The fallback module supports
mapping a requested URL (which is always the same) to
different files ...
[...]
> I don't know if it is clearer now.
It is clearer, but probably not yet clear enough :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Rolf Kulemann <ma...@rolf-kulemann.com>.
On Mon, 2003-12-15 at 10:25, Andreas Hartmann wrote:
> Rolf Kulemann wrote:
> [...]
>
> > Now each pub can override the epoz css and screen generation. I used the
> > FallbackModule, which is quite comfortable. One problem with that module
> > might be, that one can't use it for a *client side* fallback i.e. when
> > requesting a .css file. The FallbackModule is not taking care of paths
> > like resources/css/mystyle.css. The requested URI in this case has to be
> > css/mystyle.css therefor the FallbackModule should return
> > css/mystyle.css or pub/css/mystyle.css.
>
> I'm not sure how the functionality should be changed ...
>
> The purpose of the module is to allow "publication
> polymorphism" by overriding files in a publication.
> This requires to place the file in the
>
> /pubs/mypub/lenya
>
> directory, which is a contract in Lenya.
Yes, I saw, this is of course fine as it is.
>
> So the funtionality it is quite straightforward:
>
> /foo/bar
>
> translates to
>
> a) /pubs/mypub/lenya/foo/bar
> b) /foo/bar
>
> What should be changed in your opinion?
I could imagine an overriding function for files requested by the client
i.e. a web browser.
With the FallbackModule I can i.e. check for resources/css/style.css,
but I can't send the path returned by the client for insertion in a html
file or so, because it must remove the "resources" part of the path.
Client needs to request the css via /lenya/default/live/css/style.css,
thus the path returned by the FallbackModule is not the path to be used
in a <link> tag. It would be cool to have an InputModule doing this work
for me. Maybe chaning the matcher's pattern would do the trick.
(The paths I specified above maybe wrong.)
I agree, that this is maybe not part of the contract of the
FallbackModule.
I don't know if it is clearer now.
>
> Thanks for your comments,
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-user-help@cocoon.apache.org
--
Rolf Kulemann
"One planet is all you get."
PGP/GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6B4EA7EA
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Andreas Hartmann <an...@apache.org>.
Rolf Kulemann wrote:
[...]
> Now each pub can override the epoz css and screen generation. I used the
> FallbackModule, which is quite comfortable. One problem with that module
> might be, that one can't use it for a *client side* fallback i.e. when
> requesting a .css file. The FallbackModule is not taking care of paths
> like resources/css/mystyle.css. The requested URI in this case has to be
> css/mystyle.css therefor the FallbackModule should return
> css/mystyle.css or pub/css/mystyle.css.
I'm not sure how the functionality should be changed ...
The purpose of the module is to allow "publication
polymorphism" by overriding files in a publication.
This requires to place the file in the
/pubs/mypub/lenya
directory, which is a contract in Lenya.
So the funtionality it is quite straightforward:
/foo/bar
translates to
a) /pubs/mypub/lenya/foo/bar
b) /foo/bar
What should be changed in your opinion?
Thanks for your comments,
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Michael Wechner <mi...@wyona.com>.
Rolf Kulemann wrote:
>
>
>>Unfortunately I haven't read all the emails, sorry for this (btw, please
>>don't use tabs)
>
>
> Hehe. How many spaces do you use instead of a tab? Two I think.
4 within Java and 2 within XML
>
>
>>Thanks
>
>
> Also THX a lot for the integration.
no problem. A big thank you to you
Michi
>
>
>>Michi
>
>
>
--
Michael Wechner
Wyona Inc. - 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: Epoz integration patches pending...
Posted by Rolf Kulemann <ma...@rolf-kulemann.com>.
On Mon, 2003-12-15 at 10:18, Michael Wechner wrote:
> Rolf Kulemann wrote:
>
> >
> > Now each pub can override the epoz css and screen generation. I used the
> > FallbackModule, which is quite comfortable. One problem with that module
> > might be, that one can't use it for a *client side* fallback i.e. when
> > requesting a .css file. The FallbackModule is not taking care of paths
> > like resources/css/mystyle.css. The requested URI in this case has to be
> > css/mystyle.css therefor the FallbackModule should return
> > css/mystyle.css or pub/css/mystyle.css.
> >
>
> cool. Can you reimplement this into the version I have checked in.
Of course.
> Unfortunately I haven't read all the emails, sorry for this (btw, please
> don't use tabs)
Hehe. How many spaces do you use instead of a tab? Two I think.
>
> Thanks
Also THX a lot for the integration.
>
> Michi
--
Rolf Kulemann
The United States also has its native Fascists who say that they are
"100 percent American"...
-- U. S. Army (1945)
PGP/GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6B4EA7EA
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Epoz integration patches pending...
Posted by Michael Wechner <mi...@wyona.com>.
Rolf Kulemann wrote:
>
> Now each pub can override the epoz css and screen generation. I used the
> FallbackModule, which is quite comfortable. One problem with that module
> might be, that one can't use it for a *client side* fallback i.e. when
> requesting a .css file. The FallbackModule is not taking care of paths
> like resources/css/mystyle.css. The requested URI in this case has to be
> css/mystyle.css therefor the FallbackModule should return
> css/mystyle.css or pub/css/mystyle.css.
>
cool. Can you reimplement this into the version I have checked in.
Unfortunately I haven't read all the emails, sorry for this (btw, please
don't use tabs)
Thanks
Michi
--
Michael Wechner
Wyona Inc. - 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