Re: [Stripes-users] stripes:hidden
Aaron, Unfortunately frameworks are ideally all about good design and best practices... and yes are dogmatic by their very existence... a little ironic isn't it... in fact I wouldn't be surprised if Stripes was implemented this way deliberately to force avoiding bad practices... but can't be sure without looking at the code. With that said - as M.C.S. pointed out this is getting off topic BUT moreover I provided you already with a trivial solution to your issue... which you tested and works... and isn't a kludge or anything despite your misgivings. So be happy that it isn't a show stopper or something and life goes on... . Lastly, if you feel so strongly about it then go ahead and file a feature enhancement in Stripes and make your good design case. If this is truly deliberate in Stripes then IMO they got it right but who knows maybe others will see your argument and it might resonate with the developer community. Regards, --Nikolaos Aaron Stromas wrote: It is not my intent to start a flee war, but I remain convinced it is better to change one file than two. I am sorry, but Nicolaos' argument sounds dogmatic to me. I know apriori that I will be changing the hidden element to text field in the next stage. When that time comes, I will have to change only the JSP file. My action class does not to be touched. -a On Wednesday, Jly 28, 2010, M.C.S. m...@syn-online.de wrote: Hi Nikolaos, Am 28.07.2010 21:08, schrieb Nikolaos Giannopoulos: Aaron Strmas wrote: I think that in this case my initial design is better, because I have to change the JSP later anyway, and it would be only change to the JSP only. Now I have to make change in two places But I'm curious why you would have to make changes in 2 places if the variable value changes? I only see a change in 1 place if a variable is say called DEFAULT_COUNTRY and its value needs to change. No? I interpret Aaron's message this way: He will have to change the JSP for a reason independent of the magic number. Now he thinks that by placing the country code there, he improves the design because he must change just one file instead of two. Following the Separation of concerns principle, this is not the case if the needed changes just affect the layout, while the change of the country code affect the business logic. If this was good design, we all should create god files :-) So in my opinion, it is definitely better to place the US string into the bean instead of hard coding it into the JSP. Maybe another option is using a resource bundle together with an type-safe enum. This makes globally changing and reusing it somewhere else a lot of easier. But that is not really related to Stripes, so sorry for being offtopic ;-) Regards Marcus -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Nikolaos, Let me get back on topic by rephrasing my original question: why the value of the value attribute disappears from the generated HTML? Documentation states that, if present, the value attribute provides A default value for the form field. Can be a literal value, or an EL expression. It also reads: The hidden tag assigns the value attribute by scanning in the following order:... by collapsing the body content to a String, if a body is present. None of these is happening in my case. The intent of my question was to find out whether I am doing something wrong or the documentation is incorrect. It feels that the latter is the case. And I willingly concede the point that I am ill qualified to get into good framework design principles debate. [?] -a On 29 July 2010 02:13, Nikolaos Giannopoulos nikol...@brightminds.orgwrote: Aaron, Unfortunately frameworks are ideally all about good design and best practices... and yes are dogmatic by their very existence... a little ironic isn't it... in fact I wouldn't be surprised if Stripes was implemented this way deliberately to force avoiding bad practices... but can't be sure without looking at the code. With that said - as M.C.S. pointed out this is getting off topic BUT moreover I provided you already with a trivial solution to your issue... which you tested and works... and isn't a kludge or anything despite your misgivings. So be happy that it isn't a show stopper or something and life goes on... . Lastly, if you feel so strongly about it then go ahead and file a feature enhancement in Stripes and make your good design case. If this is truly deliberate in Stripes then IMO they got it right but who knows maybe others will see your argument and it might resonate with the developer community. Regards, --Nikolaos Aaron Stromas wrote: It is not my intent to start a flee war, but I remain convinced it is better to change one file than two. I am sorry, but Nicolaos' argument sounds dogmatic to me. I know apriori that I will be changing the hidden element to text field in the next stage. When that time comes, I will have to change only the JSP file. My action class does not to be touched. -a On Wednesday, Jly 28, 2010, M.C.S. m...@syn-online.de wrote: Hi Nikolaos, Am 28.07.2010 21:08, schrieb Nikolaos Giannopoulos: Aaron Strmas wrote: I think that in this case my initial design is better, because I have to change the JSP later anyway, and it would be only change to the JSP only. Now I have to make change in two places But I'm curious why you would have to make changes in 2 places if the variable value changes? I only see a change in 1 place if a variable is say called DEFAULT_COUNTRY and its value needs to change. No? I interpret Aaron's message this way: He will have to change the JSP for a reason independent of the magic number. Now he thinks that by placing the country code there, he improves the design because he must change just one file instead of two. Following the Separation of concerns principle, this is not the case if the needed changes just affect the layout, while the change of the country code affect the business logic. If this was good design, we all should create god files :-) So in my opinion, it is definitely better to place the US string into the bean instead of hard coding it into the JSP. Maybe another option is using a resource bundle together with an type-safe enum. This makes globally changing and reusing it somewhere else a lot of easier. But that is not really related to Stripes, so sorry for being offtopic ;-) Regards Marcus -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Aaron Stromas Mobile: +1 703 203 9169 35E.gif-- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Hi Aaron, Am 29.07.2010 12:50, schrieb Aaron Stromas: Let me get back on topic by rephrasing my original question: why the value of the value attribute disappears from the generated HTML? Documentation states that, if present, the value attribute provides A default value for the form field. Can be a literal value, or an EL expression. It also reads: The hidden tag assigns the value attribute by scanning in the following order:... by collapsing the body content to a String, if a body is present. None of these is happening in my case. The intent of my question was to find out whether I am doing something wrong or the documentation is incorrect. It feels that the latter is the case. this usually happens if you are using BeanFirstPopulationStrategy. The JavaDoc describes the case that you use the default population strategy, which rates request parameters over values within the corresponding action bean. Could this be the solution in your case? Regards Marcus -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Yes, absolutely. Thank you, Marcus. -a On Jul 29, 2010, at 8:56, M.C.S. m...@syn-online.de wrote: Hi Aaron, Am 29.07.2010 12:50, schrieb Aaron Stromas: Let me get back on topic by rephrasing my original question: why the value of the value attribute disappears from the generated HTML? Documentation states that, if present, the value attribute provides A default value for the form field. Can be a literal value, or an EL expression. It also reads: The hidden tag assigns the value attribute by scanning in the following order:... by collapsing the body content to a String, if a body is present. None of these is happening in my case. The intent of my question was to find out whether I am doing something wrong or the documentation is incorrect. It feels that the latter is the case. this usually happens if you are using BeanFirstPopulationStrategy. The JavaDoc describes the case that you use the default population strategy, which rates request parameters over values within the corresponding action bean. Could this be the solution in your case? Regards Marcus -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] stripes:hidden
Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Aaron, You shouldn't avoid hard-coding values in a JSP... even if it something as simple as a default value. Have you tried putting the value as a constant in your action bean and referring to it from there? (the idea is if you have multiple JSPs then the value need only be maintained in one place) If it works drop us a note as I am curious about this issue as well... . --Nikolaos Aaron Stromas wrote: Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Hi Nikolaos, Yes, initializing property in action works fine. I think that in this case my initial design is better, because I have to change the JSP later anyway, and it would be only change to the JSP only. Now I have to make change in two places -a On Jul 28, 2010, at 12:17, Nikolaos Giannopoulos nikol...@brightminds.org wrote: Aaron, You shouldn't avoid hard-coding values in a JSP... even if it something as simple as a default value. Have you tried putting the value as a constant in your action bean and referring to it from there? (the idea is if you have multiple JSPs then the value need only be maintained in one place) If it works drop us a note as I am curious about this issue as well... . --Nikolaos Aaron Stromas wrote: Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Nikolaos Giannopoulos wrote: Aaron, You shouldn't avoid hard-coding values in a JSP... even if it something as simple as a default value. Ha... er... should avoid Have you tried putting the value as a constant in your action bean and referring to it from there? (the idea is if you have multiple JSPs then the value need only be maintained in one place) If it works drop us a note as I am curious about this issue as well... . --Nikolaos Aaron Stromas wrote: Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
I understood On Jul 28, 2010, at 13:22, Nikolaos Giannopoulos nikol...@brightminds.org wrote: Nikolaos Giannopoulos wrote: Aaron, You shouldn't avoid hard-coding values in a JSP... even if it something as simple as a default value. Ha... er... should avoid Have you tried putting the value as a constant in your action bean and referring to it from there? (the idea is if you have multiple JSPs then the value need only be maintained in one place) If it works drop us a note as I am curious about this issue as well... . --Nikolaos Aaron Stromas wrote: Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Aaron, Glad to see it works :-) I corrected my typo before seeing your reply... . You are free to do what you like in the JSP... but don't say it is better design... because unfortunately it isn't... . Scriplets and hard coding in JSPs is bad design period :-) Yes - if there is one variable used in one JSP then technically you are coding in 2 places... but that doesn't make it better or best practice... . The other argument might be that it is easier to put it in the JSP because JSP's can be automatically re-compiled on changes but this doesn't hold water either because in production best practice has it to disable auto-recompile of JSPs for a number of reasons (e.g. more performant, security w.r.t. defacing, etc...). Perhaps its more convenient for you but convenience and good design don't always go hand in hand... often its a trade off. In any event, it seems like you have little choice. But I'm curious why you would have to make changes in 2 places if the variable value changes? I only see a change in 1 place if a variable is say called DEFAULT_COUNTRY and its value needs to change. No? --Nikolaos Aaron Strmas wrote: Hi Nikolaos, Yes, initializing property in action works fine. I think that in this case my initial design is better, because I have to change the JSP later anyway, and it would be only change to the JSP only. Now I have to make change in two places -a On Jul 28, 2010, at 12:17, Nikolaos Giannopoulos nikol...@brightminds.org mailto:nikol...@brightminds.org wrote: Aaron, You shouldn't avoid hard-coding values in a JSP... even if it something as simple as a default value. Have you tried putting the value as a constant in your action bean and referring to it from there? (the idea is if you have multiple JSPs then the value need only be maintained in one place) If it works drop us a note as I am curious about this issue as well... . --Nikolaos Aaron Stromas wrote: Greetings, My application has a counttry property whose value eventually will be input in the form but for now is defaulted to US, so I attempted to put it in the hidden field in the JSP: stripes:hidden name=country value=US/ The generated HTML is input type=hidden name=country value=/ The same HTML is generated for stripes:hidden name=countryUS/stripes:hidden. The oddest thing is that the value is stripped and the same HTML is produced when I put input type=hidden name=country value=US/ directly in JSP. Is Websphere's JSP engine sabotaging the works? Anybody knows? Just curious... Thanks, -a -- Aaron Stromas Mobile: +1 703 203 9169 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org mailto:nikol...@brightminds.org w. www.brightminds.org http://www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden
Hi Nikolaos, Am 28.07.2010 21:08, schrieb Nikolaos Giannopoulos: Aaron Strmas wrote: I think that in this case my initial design is better, because I have to change the JSP later anyway, and it would be only change to the JSP only. Now I have to make change in two places But I'm curious why you would have to make changes in 2 places if the variable value changes? I only see a change in 1 place if a variable is say called DEFAULT_COUNTRY and its value needs to change. No? I interpret Aaron's message this way: He will have to change the JSP for a reason independent of the magic number. Now he thinks that by placing the country code there, he improves the design because he must change just one file instead of two. Following the Separation of concerns principle, this is not the case if the needed changes just affect the layout, while the change of the country code affect the business logic. If this was good design, we all should create god files :-) So in my opinion, it is definitely better to place the US string into the bean instead of hard coding it into the JSP. Maybe another option is using a resource bundle together with an type-safe enum. This makes globally changing and reusing it somewhere else a lot of easier. But that is not really related to Stripes, so sorry for being offtopic ;-) Regards Marcus -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden binding order (and boolean properties)
I don't see why a body would be more important than an attribute; do you have an example of a tag for which this is the case? What you could do is use a regular HTML input tag; that way, you can be certain that Stripes won't change its value. Levi Op 17 sep 2009 om 05:09 heeft Brandon Atkinson brandon.n.atkin...@gmail.com het volgende geschreven:\ Hi all, I'm trying to understand the reasoning for the hidden tag's property binding order. I understand why the HSR and ActionBean override the default value set in the stripes:hidden tag, but shouldn't the body override all of these? To illustrate, assume there is a boolean property called 'confirmed' that has a false value on the ActionBean. Given this code: stripes:hidden name=confirmedtrue/stripes:hidden I would expect that confirmed would be set to true in the hidden field, since I've explicitly set the value in the tag body. To me, setting the tag body is the ultimate override. If I wanted to set a default value, I'd use this: stripes:hidden name=confirmed value=true/stripes:hidden Can anyone explain why tag body doesn't override values in HSR and ActionBean in this case? -Brandon Atkinson --- --- --- - Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] stripes:hidden binding order (and boolean properties)
Hi Levi, using the regular HTML tag results in losing encrypted fields. I would be glad if there was a way to use the s:hidden field like a regular tag (value over bean field) - to be able to use the encryption support. Marcus Levi Hoogenberg schrieb: I don't see why a body would be more important than an attribute; do you have an example of a tag for which this is the case? What you could do is use a regular HTML input tag; that way, you can be certain that Stripes won't change its value. Levi Op 17 sep 2009 om 05:09 heeft Brandon Atkinson brandon.n.atkin...@gmail.com het volgende geschreven:\ Hi all, I'm trying to understand the reasoning for the hidden tag's property binding order. I understand why the HSR and ActionBean override the default value set in the stripes:hidden tag, but shouldn't the body override all of these? To illustrate, assume there is a boolean property called 'confirmed' that has a false value on the ActionBean. Given this code: stripes:hidden name=confirmedtrue/stripes:hidden I would expect that confirmed would be set to true in the hidden field, since I've explicitly set the value in the tag body. To me, setting the tag body is the ultimate override. If I wanted to set a default value, I'd use this: stripes:hidden name=confirmed value=true/stripes:hidden Can anyone explain why tag body doesn't override values in HSR and ActionBean in this case? -Brandon Atkinson --- --- --- - Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
