You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Kunal H. Parikh" <ku...@carsales.com.au> on 2004/02/18 02:18:23 UTC
Tiles and website skinnability
Hi All!
I am attempting to "tile" my website.
However, I have a need to skin websites based on varied requirements,
wherein, the "layout" of the site remains the same, with the exception of
the graphics.
What I additionally need to do, is call a different style sheet based on the
URL.
Can someone throw some light in this area ?
TIA,
Kunal
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Tiles and website skinnability
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Havn't done this, but try looking at the Dynamic L&F Chapter in
tilesAdvancedFeatures.pdf
http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf
Niall
----- Original Message -----
From: "Kunal H. Parikh" <ku...@carsales.com.au>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
Sent: Wednesday, February 18, 2004 1:18 AM
Subject: Tiles and website skinnability
Hi All!
I am attempting to "tile" my website.
However, I have a need to skin websites based on varied requirements,
wherein, the "layout" of the site remains the same, with the exception of
the graphics.
What I additionally need to do, is call a different style sheet based on the
URL.
Can someone throw some light in this area ?
TIA,
Kunal
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Validator and DispatchAction
Posted by Renato Romano <r....@set-network.com>.
That's just what I supposed. DispatchAction are fine, but when you need
finer control Action fits best!! Maybe next time ;-))
Thanks anyway
Renato
____________________________________
Renato Romano
Sistemi e Telematica S.p.A.
Calata Grazie - Vial Al Molo Giano
16127 - GENOVA
e-mail: r.romano@set-network.com
Tel.: 010 2712603
_____________________________________
-----Original Message-----
From: Carl Walker [mailto:walkerce@georgetown.edu]
Sent: mercoledì 18 febbraio 2004 16.43
To: Struts Users Mailing List
Subject: Re: Validator and DispatchAction
I ran into the same problem and converted all my DispatchActions to
Actions. The downside is that there are more class files, but the
mappings seem cleaner, especially in handling the 'input' attribute for
<html:errors />.
Also, using Actions lets me specify different values for the 'validate'
attribute. For example, I use the same form to lookup a records as I do
to update it. In the case of the lookup, the Action pulls an identifier
from the DynaActionForm that doesn't need to be validated
(validate=false for this mapping). In the case of the update, full
validation of all fields is required, so validate=true for this one.
Renato Romano wrote:
> I'm quite new to the validator framework, and was trying to figure out
> how to use it. My situation is:
> 1) I want to perform server side validation, and so I made my form
> extend ValidatorForm;
> 2) the action that processes my form is a DispatchAction, so I have
> methods like "edit", "save" "list", all associated with the same form;
> 3) I call http://blabla/myapp/myAction.do?methodName=edit to have the
> app present me with an empty form;
> 4) When processing this action, struts allocates the form and calls
> the validate method, which of course causes validation errors to be
> produced, and the request to be forwarded to the "input" element of my
> action, which, as usual, is the same jsp which contains the form;
> 5) since the page finds some errors (the form is empty!!) they are
> shown by the <html:errors/> tag.
>
> The only think I can imagine is to have a separate action in
> struts-config, which takes no form and simply redirects control to the
> jsp page which shows the (html) form. This should avoid Struts from
> calling the validate method, and hence <html:errors/> should show
> nothing.
>
> Of course this would change a bit the logic we already placed in the
> application actions: for example action.do?methodName=edit in our
> architecture should present an empty form, while
> action.do?m=edit&id=88 should fill the form with the properties of the
> object with id 88, and then forward to the same jsp page, which then
> shows that object ready to be modified. If my above consideration is
> correct I should define two separate actions in struts-config, and let
> the links be something like newObject.do (for the presentation of an
> empty form) and unchanged for the "loading" of an object.
>
> Is all this correct ?Are there alternative approaches? Should I quit
> server side validation and only use client-side (which does not suffer
> from this problem)? Any help is very appreciated.
>
> Renato
>
> ____________________________________
> Renato Romano
> Sistemi e Telematica S.p.A.
> Calata Grazie - Vial Al Molo Giano
> 16127 - GENOVA
>
> e-mail: r.romano@set-network.com
> Tel.: 010 2712603
> _____________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Validator and DispatchAction
Posted by Carl Walker <wa...@georgetown.edu>.
I ran into the same problem and converted all my DispatchActions to
Actions. The downside is that there are more class files, but the mappings
seem cleaner, especially in handling the 'input' attribute for <html:errors
/>.
Also, using Actions lets me specify different values for the 'validate'
attribute. For example, I use the same form to lookup a records as I do to
update it. In the case of the lookup, the Action pulls an identifier from
the DynaActionForm that doesn't need to be validated (validate=false for
this mapping). In the case of the update, full validation of all fields is
required, so validate=true for this one.
Renato Romano wrote:
> I'm quite new to the validator framework, and was trying to figure out
> how to use it. My situation is:
> 1) I want to perform server side validation, and so I made my form
> extend ValidatorForm;
> 2) the action that processes my form is a DispatchAction, so I have
> methods like "edit", "save" "list", all associated with the same form;
> 3) I call http://blabla/myapp/myAction.do?methodName=edit to have the
> app present me with an empty form;
> 4) When processing this action, struts allocates the form and calls the
> validate method, which of course causes validation errors to be
> produced, and the request to be forwarded to the "input" element of my
> action, which, as usual, is the same jsp which contains the form;
> 5) since the page finds some errors (the form is empty!!) they are shown
> by the <html:errors/> tag.
>
> The only think I can imagine is to have a separate action in
> struts-config, which takes no form and simply redirects control to the
> jsp page which shows the (html) form. This should avoid Struts from
> calling the validate method, and hence <html:errors/> should show
> nothing.
>
> Of course this would change a bit the logic we already placed in the
> application actions: for example action.do?methodName=edit in our
> architecture should present an empty form, while action.do?m=edit&id=88
> should fill the form with the properties of the object with id 88, and
> then forward to the same jsp page, which then shows that object ready to
> be modified. If my above consideration is correct I should define two
> separate actions in struts-config, and let the links be something like
> newObject.do (for the presentation of an empty form) and unchanged for
> the "loading" of an object.
>
> Is all this correct ?Are there alternative approaches? Should I quit
> server side validation and only use client-side (which does not suffer
> from this problem)?
> Any help is very appreciated.
>
> Renato
>
> ____________________________________
> Renato Romano
> Sistemi e Telematica S.p.A.
> Calata Grazie - Vial Al Molo Giano
> 16127 - GENOVA
>
> e-mail: r.romano@set-network.com
> Tel.: 010 2712603
> _____________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Validator and DispatchAction
Posted by Renato Romano <r....@set-network.com>.
I'm quite new to the validator framework, and was trying to figure out
how to use it. My situation is:
1) I want to perform server side validation, and so I made my form
extend ValidatorForm;
2) the action that processes my form is a DispatchAction, so I have
methods like "edit", "save" "list", all associated with the same form;
3) I call http://blabla/myapp/myAction.do?methodName=edit to have the
app present me with an empty form;
4) When processing this action, struts allocates the form and calls the
validate method, which of course causes validation errors to be
produced, and the request to be forwarded to the "input" element of my
action, which, as usual, is the same jsp which contains the form;
5) since the page finds some errors (the form is empty!!) they are shown
by the <html:errors/> tag.
The only think I can imagine is to have a separate action in
struts-config, which takes no form and simply redirects control to the
jsp page which shows the (html) form. This should avoid Struts from
calling the validate method, and hence <html:errors/> should show
nothing.
Of course this would change a bit the logic we already placed in the
application actions: for example action.do?methodName=edit in our
architecture should present an empty form, while action.do?m=edit&id=88
should fill the form with the properties of the object with id 88, and
then forward to the same jsp page, which then shows that object ready to
be modified. If my above consideration is correct I should define two
separate actions in struts-config, and let the links be something like
newObject.do (for the presentation of an empty form) and unchanged for
the "loading" of an object.
Is all this correct ?Are there alternative approaches? Should I quit
server side validation and only use client-side (which does not suffer
from this problem)?
Any help is very appreciated.
Renato
____________________________________
Renato Romano
Sistemi e Telematica S.p.A.
Calata Grazie - Vial Al Molo Giano
16127 - GENOVA
e-mail: r.romano@set-network.com
Tel.: 010 2712603
_____________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Tiles and website skinnability
Posted by Guillermo Meyer <gm...@interbanking.com.ar>.
You can use Xkins to add skins to the website while still using tiles
(http://xkins.sourceforge.net).
You can use XkinsForms tags or create your own taglibs and use xkins to
generate HTML.
You can use css with Xkins, and each skin can have it's own path for
it's css:
For example, if you have this css files in your webapp structure:
/ROOT/skins/skin1/css/styles.css
/ROOT/skins/skin2/css/styles.css
/ROOT/skins/skin3/css-styles/myStyles.css
And you have this Xkin definition
<xkins>
<processor
type="ar.com.koalas.xkins.processor.VelocityTemplateProcessor"/>
<skin name="skin1" url="/skins/skin1">
<path name="css" url="/css"/>
<template name="stylesheet">
<content><![CDATA[
<link rel='STYLESHEET'
href='$res_stylesheet'></link>
]]></content>
<element name="stylesheet" path="css"
url="/styles.css"/>
</template>
</skin>
<!-- extends skin1 and only overrides skin url-->
<skin name="skin2" url="/skins/skin2" extends="skin1"/>
<!-- extends skin1 and overrides skin url, css-path url and
stylesheet template element url -->
<skin name="skin3" url="/skins/skin3" extends="skin1">
<path name="css" url="/css-styles"/>
<template name="stylesheet">
<element name="stylesheet" path="css"
url="/myStyles.css"/>
</template>
</skin>
</xkins>
In your JSP you can insert the CSS reference according to the user skin:
<%@ taglib uri="/WEB-INF/tld/xkins.tld" prefix="xkin" %>
<xkin:template name="stylesheet"/>
If user has selected skin2, the following html code will be produced:
<link rel='STYLESHEET' href='/skins/skin2/css/styles.css'></link>
If you use Xkins just for this, you can win in organization of your
urls, files, etc. But you can do the same thing to produce different
tables, frames, buttons, titles, etc.
Cheers.
Guillermo
-----Original Message-----
From: Kunal H. Parikh [mailto:kunalp@carsales.com.au]
Sent: Martes, 17 de Febrero de 2004 10:18 p.m.
To: 'Struts Users Mailing List'
Subject: Tiles and website skinnability
Hi All!
I am attempting to "tile" my website.
However, I have a need to skin websites based on varied requirements,
wherein, the "layout" of the site remains the same, with the exception
of the graphics.
What I additionally need to do, is call a different style sheet based on
the URL.
Can someone throw some light in this area ?
TIA,
Kunal
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
NOTA DE CONFIDENCIALIDAD
Este mensaje (y sus anexos) es confidencial, esta dirigido exclusivamente a las personas direccionadas en el mail y puede contener informacion (i)de propiedad exclusiva de Interbanking S.A. o (ii) amparada por el secreto profesional. Cualquier opinion en el contenido, es exclusiva de su autor y no representa necesariamente la opinion de Interbanking S.A. El acceso no autorizado, uso, reproduccion, o divulgacion esta prohibido. Interbanking S.A no asumira responsabilidad ni obligacion legal alguna por cualquier informacion incorrecta o alterada contenida en este mensaje. Si usted ha recibido este mensaje por error, le rogamos tenga la amabilidad de destruirlo inmediatamente junto con todas las copias del mismo, notificando al remitente. No debera utilizar, revelar, distribuir, imprimir o copiar este mensaje ni ninguna de sus partes si usted no es el destinatario. Muchas gracias.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org