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.org>wrote:

> 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

Reply via email to