Re: validation and action names with slashes
Jeromy Evans wrote: Roberto Nunnari wrote: Jeromy Evans wrote: Roberto Nunnari wrote: This is what I intend to do. At the moment the CodeBehind/Convention plugin estimates the name of view candidates (eg. package-action-result.jsp) This change would just need to extend that to check if a tile exists with that name. This change will mean that @Result's are only required for the exceptional cases (those results that need to break the Tiles naming convention). Yes! That would be great! Are you going to do the coding yourself? Yes, it's on my todo list. If I get round to, I may look into the code myself.. I'd be glad to contribute to struts. -- Robi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Jeromy Evans wrote: Roberto Nunnari wrote: Maybe the convention plugin should look into the tiles.xml file, or check to see if the tiles plugin or tiles listener are in the game.. Most probably, the definition names in tiles.xml should follow the conventions, so that definition name=auctionView.. becomes definition name=auction and definition name=auctionInput.. becomes definition name=auction-input etc.. This is what I intend to do. At the moment the CodeBehind/Convention plugin estimates the name of view candidates (eg. package-action-result.jsp) This change would just need to extend that to check if a tile exists with that name. This change will mean that @Result's are only required for the exceptional cases (those results that need to break the Tiles naming convention). Yes! That would be great! Are you going to do the coding yourself? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Roberto Nunnari wrote: Jeromy Evans wrote: Roberto Nunnari wrote: This is what I intend to do. At the moment the CodeBehind/Convention plugin estimates the name of view candidates (eg. package-action-result.jsp) This change would just need to extend that to check if a tile exists with that name. This change will mean that @Result's are only required for the exceptional cases (those results that need to break the Tiles naming convention). Yes! That would be great! Are you going to do the coding yourself? Yes, it's on my todo list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Hi Martin. I must admit that I have not thought about it at all, but I'll try here to come up with something, and to tell you how I use tiles. I usually end up with a moderate long struts.xml a *very long* tiles.xml (maybe that's not the best way to use tiles, but it's the way I use it. Antonio, please add here if you wish..). I use tiles in a way that I have all tiles predefined in tiles.xml and all final page composition in a couple of files (the template files). The template files have *all* the tiles:insertAttribute .../ tags, as this: tiles:insertAttribute name=header/ and all the other tiles never use insertAttribute again. So, how could the convention plugin help with tiles? I'd rather not use annotations at all for results mapping. I don't know if it is already that way, but I believe that instead of having to add annotations to override behaviour the convention plugin should consider struts.xml and tiles.xml If the above files have not a definition for the current request, then use the convention, otherwise use that definition to ovverride the behaviour. Maybe the convention plugin should look into the tiles.xml file, or check to see if the tiles plugin or tiles listener are in the game.. Most probably, the definition names in tiles.xml should follow the conventions, so that definition name=auctionView.. becomes definition name=auction and definition name=auctionInput.. becomes definition name=auction-input etc.. so that: URL: /auction translates to: Action class: rootpkg.Auction tile definition: auction (or auction-input if the result is input) in order to optimise for applications that don't use tiles, you could have a property in struts.properties that tells the convention plugin to consider tiles or not, while trying to determine the view for the request so that if tiles should be considered, in the order try: tiles, jsp, velocity, etc.. I hope this helps. Best regards. Robi here's a little part of my tiles.xml definition name=mainLayout template=/WEB-INF/tiles/layouts/classicLayout.jsp put-attribute name=title value=myecommerce homepage / put-attribute name=header value=/WEB-INF/tiles/header.jsp / put-attribute name=other value=/WEB-INF/tiles/other.jsp / put-attribute name=categories value=/WEB-INF/tiles/categories.jsp / put-attribute name=userMenu value=/WEB-INF/tiles/userMenu.jsp / put-attribute name=messages value=/WEB-INF/tiles/messages.jsp / put-attribute name=body value=/WEB-INF/tiles/default_body.jsp / put-attribute name=siteOwner value=/WEB-INF/tiles/siteOwner.jsp / put-attribute name=banners value=/WEB-INF/tiles/banners.jsp / put-attribute name=footer value=/WEB-INF/tiles/footer.jsp / /definition definition name=home extends=mainLayout template=/WEB-INF/tiles/layouts/classicLayoutHome.jsp put-attribute name=title value=myecommerce home page / put-attribute name=body value=/WEB-INF/tiles/content/home.jsp / /definition definition name=help extends=home put-attribute name=title value=myecommerce help page / put-attribute name=body value=/WEB-INF/tiles/content/help.jsp / /definition definition name=about extends=home put-attribute name=title value=myecommerce about page / put-attribute name=body value=/WEB-INF/tiles/content/about.jsp / /definition definition name=auctionView extends=mainLayout put-attribute name=title value=View Auction / put-attribute name=body value=/WEB-INF/tiles/content/auctionView.jsp / /definition Martin wrote: Roberto- Just to clarify..how should the Results mapping annotations configuration be introduced? Thanks Martin-- - Original Message - From: Roberto Nunnari [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, June 21, 2008 7:25 PM Subject: Re: validation and action names with slashes Jeromy Evans wrote: Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. WOW.. The convention plugin rocks! I like it! I'm writing action classes and related jsps and struts finds the right Action class and jsp without having to touch the struts.xml I don't even have the struts.xml file! This is a very confortable way of writing web applications. It works with Tiles, but you have to explicitly declare each @Result(type=TilesResult.class,value=xxx) which I find really annoying (as you say, it breaks the convenience of the convention). I've been intending to raise that over at struts-dev, which I'll do now. Yes.. Please do. If it would support tiles, I'd start using it right away, but like this, no way. I don't like the idea of having to define result mappings in java source code.. and to say it all.. I don't like annotations, although I admit
Re: validation and action names with slashes
Roberto Nunnari wrote: Maybe the convention plugin should look into the tiles.xml file, or check to see if the tiles plugin or tiles listener are in the game.. Most probably, the definition names in tiles.xml should follow the conventions, so that definition name=auctionView.. becomes definition name=auction and definition name=auctionInput.. becomes definition name=auction-input etc.. This is what I intend to do. At the moment the CodeBehind/Convention plugin estimates the name of view candidates (eg. package-action-result.jsp) This change would just need to extend that to check if a tile exists with that name. This change will mean that @Result's are only required for the exceptional cases (those results that need to break the Tiles naming convention). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
built! going to experiment a bit. Thank you and best regards. -- Robi Jeromy Evans wrote: Roberto Nunnari wrote: Jeromy Evans wrote: Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. should I take it from the sandbox then? just cd sandbox mvn package? Yes. cd sandbox/struts-convention-plugin mvn clean install You'll then be able to use struts-convention-plugin-2.1.3-SNAPSHOT in your test application. You may need to ensure the sandbox, struts2, xwork and struts-annotations are up-to-date though (but the build is broken at this moment) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Jeromy Evans wrote: Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. WOW.. The convention plugin rocks! I like it! I'm writing action classes and related jsps and struts finds the right Action class and jsp without having to touch the struts.xml I don't even have the struts.xml file! This is a very confortable way of writing web applications. It works with Tiles, but you have to explicitly declare each @Result(type=TilesResult.class,value=xxx) which I find really annoying (as you say, it breaks the convenience of the convention). I've been intending to raise that over at struts-dev, which I'll do now. Yes.. Please do. If it would support tiles, I'd start using it right away, but like this, no way. I don't like the idea of having to define result mappings in java source code.. and to say it all.. I don't like annotations, although I admit that at times annotations are very useful. :-) Best regards. Robi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Roberto- Just to clarify..how should the Results mapping annotations configuration be introduced? Thanks Martin-- - Original Message - From: Roberto Nunnari [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, June 21, 2008 7:25 PM Subject: Re: validation and action names with slashes Jeromy Evans wrote: Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. WOW.. The convention plugin rocks! I like it! I'm writing action classes and related jsps and struts finds the right Action class and jsp without having to touch the struts.xml I don't even have the struts.xml file! This is a very confortable way of writing web applications. It works with Tiles, but you have to explicitly declare each @Result(type=TilesResult.class,value=xxx) which I find really annoying (as you say, it breaks the convenience of the convention). I've been intending to raise that over at struts-dev, which I'll do now. Yes.. Please do. If it would support tiles, I'd start using it right away, but like this, no way. I don't like the idea of having to define result mappings in java source code.. and to say it all.. I don't like annotations, although I admit that at times annotations are very useful. :-) Best regards. Robi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Anybody on this, please?
--
Robi
Roberto Nunnari wrote:
Hello.
I'd like to use declarative Action-alias field validation for
several Actions/methods in my S2 webpapp.
S2 let's me do in struts.xml elegant things like:
package name=admin extends=tiles-default namespace=/admin
...
action name=*/* method={2} class=mypkg.admin.{1}Action
.. my results..
/action
...
/package
and then use it in my jsps:
s:url action=Category/create namespace=/admin id=newURL/
..but in order to add declarative validation, that would require
a file named:
CategoryAction/create-validation.xml
but '/' is not a character allowed in filenames.
How to go with this dilemma? Should I drop the slashes in
action names and use more verbose and less flexible declarations
in struts.xml, or is there a better way?
Thank you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Oops.. little typo! Correction below, in context.
Maybe using a different separator in action name, like '!'
instead of '/' could help..
But now this leads me to a more general question:
Can action names containing '*' be mapped at all to Action-alias validation?
Thank you!
--
Robi
Roberto Nunnari wrote:
Hello.
I'd like to use declarative Action-alias field validation for
several Actions/methods in my S2 webpapp.
S2 let's me do in struts.xml elegant things like:
package name=admin extends=tiles-default namespace=/admin
...
action name=*/* method={2} class=mypkg.admin.{1}Action
.. my results..
/action
...
/package
and then use it in my jsps:
s:url action=Category/create namespace=/admin id=newURL/
..but in order to add declarative validation, that would require
a file named:
CategoryAction/create-validation.xml
CategoryAction-Category/create-validation.xml
but '/' is not a character allowed in filenames.
How to go with this dilemma? Should I drop the slashes in
action names and use more verbose and less flexible declarations
in struts.xml, or is there a better way?
Thank you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Hi guys.
From my tests here's what I found:
1) action names with '/' are not usable for declarative action-alias
validation because of java package name (and most probably filesystem )
incompatibilities
2) action names with wildcards and '!' (ie '*!*') are not usable for
declarative action-alias validation. No idea why.
3) action names with wildcards and '_' (ie '*_*') do work for
declarative action-alias validation.
So, for completeness and future reference (should it go into the wiki?),
here's how I configured struts.xml:
action name=*_* method={2}
class=mypkg.admin.{1}Action
result name=view type=tiles{1}View/result
result name=edit type=tiles{1}Edit/result
result name=input type=tiles{1}Edit/result
result name=success-redirect
type=redirect-action{1}_{2}/result
/action
and then use it in my jsps:
s:url action=Category_create namespace=/admin id=newURL/
..and in order to add declarative validation, the above requires
a file named:
CategoryAction-Category_create-validation.xml
Best regards.
--
Robi
Roberto Nunnari wrote:
Oops.. little typo! Correction below, in context.
Maybe using a different separator in action name, like '!'
instead of '/' could help..
But now this leads me to a more general question:
Can action names containing '*' be mapped at all to Action-alias
validation?
Thank you!
--
Robi
Roberto Nunnari wrote:
Hello.
I'd like to use declarative Action-alias field validation for
several Actions/methods in my S2 webpapp.
S2 let's me do in struts.xml elegant things like:
package name=admin extends=tiles-default namespace=/admin
...
action name=*/* method={2} class=mypkg.admin.{1}Action
.. my results..
/action
...
/package
and then use it in my jsps:
s:url action=Category/create namespace=/admin id=newURL/
..but in order to add declarative validation, that would require
a file named:
CategoryAction/create-validation.xml
CategoryAction-Category/create-validation.xml
but '/' is not a character allowed in filenames.
How to go with this dilemma? Should I drop the slashes in
action names and use more verbose and less flexible declarations
in struts.xml, or is there a better way?
Thank you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Roberto Nunnari wrote:
2) action names with wildcards and '!' (ie '*!*') are not usable for
declarative action-alias validation. No idea why.
This works:
action name=manageAccount!* method=do{1}
class=package.ManageAccountAction
matches the XML validation:
ManageAccountAction-manageAccount!ChangePassword-validation.xml
where doChangePassword is the name of the method to be invoked in
ManageAccountAction
The following setting is important as the ! is just a separator char
(nothing special)
# disable the old (bang) XWorks2 notation of dynamic invocation of
actions. Wildcards are still permitted
struts.enable.DynamicMethodInvocation = false
My advice is not to use this feature of Struts2 and instead keep it
simple (follow the convention of the Convention plugin, even if not in
use yet).
regards,
Jeromy Evans.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Hi Jeromy!
The Convention plugin looks very interesting! Does it work
with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend.
What about mixing it with tiles?
Would it require specifying tiles results thus breaking
the convenience of conventions?
--
Robi
Jeromy Evans wrote:
Roberto Nunnari wrote:
2) action names with wildcards and '!' (ie '*!*') are not usable for
declarative action-alias validation. No idea why.
This works:
action name=manageAccount!* method=do{1}
class=package.ManageAccountAction
matches the XML validation:
ManageAccountAction-manageAccount!ChangePassword-validation.xml
where doChangePassword is the name of the method to be invoked in
ManageAccountAction
The following setting is important as the ! is just a separator char
(nothing special)
# disable the old (bang) XWorks2 notation of dynamic invocation of
actions. Wildcards are still permitted
struts.enable.DynamicMethodInvocation = false
My advice is not to use this feature of Struts2 and instead keep it
simple (follow the convention of the Convention plugin, even if not in
use yet).
regards,
Jeromy Evans.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. It works with Tiles, but you have to explicitly declare each @Result(type=TilesResult.class,value=xxx) which I find really annoying (as you say, it breaks the convenience of the convention). I've been intending to raise that over at struts-dev, which I'll do now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation and action names with slashes
Roberto Nunnari wrote: Jeromy Evans wrote: Roberto Nunnari wrote: Hi Jeromy! The Convention plugin looks very interesting! Does it work with 2.1.3-SNAPSHOT ? I'd like to give it a try this weekend. What about mixing it with tiles? Would it require specifying tiles results thus breaking the convenience of conventions? It works with 2.1.3-SNAPSHOT but isn't distributed with it as it's still in the sandbox. should I take it from the sandbox then? just cd sandbox mvn package? Yes. cd sandbox/struts-convention-plugin mvn clean install You'll then be able to use struts-convention-plugin-2.1.3-SNAPSHOT in your test application. You may need to ensure the sandbox, struts2, xwork and struts-annotations are up-to-date though (but the build is broken at this moment) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
