struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederik Minatchy <frederi...@yahoo.fr>
Subject Re: About the better way to implement a JSP in read/edit mode
Date Thu, 11 Mar 2010 15:27:52 GMT
After having read several answers I think your right...

it depends mainly on the peoples working on the project. If they are abble to implement the
same kind of JSP.

Regards


Fred

--- En date de : Jeu 11.3.10, Paweł Wielgus <poulwiel@gmail.com> a écrit :

> De: Paweł Wielgus <poulwiel@gmail.com>
> Objet: Re: About the better way to implement a JSP in read/edit mode
> À: "Struts Users Mailing List" <user@struts.apache.org>
> Date: Jeudi 11 mars 2010, 15h22
> Hi all,
> no one's right.
> One file need more presentation logic - which is bad and
> harder to
> maintain also presenting edit and view in one place might
> not be the
> most ergonomic way for users.
> On the other hand, one file is less than two which might be
> good. Also
> with one file you will never forget to present in view file
> new field
> that just had been added to model in edit.
> 
> The point here is that there is no simple answear for this
> question.
> 
> Best greetings,
> Pawel Wielgus.
> 
> 2010/3/10, Frederik Minatchy <frederik78@yahoo.fr>:
> > many thanks :)
> >
> > I appreciate your response
> >
> >
> >
> >
> > --- En date de : Mer 10.3.10, Alex Rodriguez Lopez
> <alopez@flordeutopia.pt>
> > a écrit :
> >
> >> De: Alex Rodriguez Lopez <alopez@flordeutopia.pt>
> >> Objet: Re: About the better way to implement a JSP
> in read/edit mode
> >> À: user@struts.apache.org
> >> Date: Mercredi 10 mars 2010, 10h24
> >> I do tend to think that the less
> >> files the better. Here it's the same
> >> with the number of files for actions/jsp, one can
> use more
> >> actions, ore
> >> less actions but more methods inside. Same with
> jsp, I do
> >> think it's
> >> better with less files, but a colleague here also
> thinks
> >> the opposite,
> >> sometimes with less files you have to provide
> aditional
> >> checks or cases
> >> so one file fits all possible use cases.
> >>
> >> I think it's more elegant for me with same file
> for read
> >> and edit, but
> >> others might dissagree, not sure if a way is
> better than
> >> the other :)
> >>
> >> Alex
> >>
> >> Em 10-03-2010 09:43, Frederik Minatchy escreveu:
> >> > I think I will think about that during my
> next Struts2
> >> project :)
> >> >
> >> > But about my question "Do I have to develop
> several
> >> interfaces with the same fields in read mode and
> edit
> >> mode?"
> >> >
> >> > Does this mean that I should use the same JSP
> to do
> >> both?
> >> >
> >> > (that's already what I have done... but a
> colleague
> >> thinks that it is not the better way... who's
> right? :) )
> >> >
> >> >
> >> >
> >> >
> >> > --- En date de : Mer 10.3.10, Angelo
> zerr<angelo.zerr@gmail.com>
> >> a écrit :
> >> >
> >> >> De: Angelo zerr<angelo.zerr@gmail.com>
> >> >> Objet: Re: About the better way to
> implement a JSP
> >> in read/edit mode
> >> >> À: "Struts Users Mailing List"<user@struts.apache.org>
> >> >> Date: Mercredi 10 mars 2010, 9h26
> >> >> Hi Frederik,
> >> >>
> >> >> FormView can works with any HTML or JSP
> Taglib. It
> >> update
> >> >> HTML switch
> >> >> configuration and state of your HTML
> field.
> >> Formview works
> >> >> with Struts 1.x
> >> >> to use information about validation.xml
> (like
> >> required,
> >> >> date...). I don't
> >> >> know how works Struts 2.x validation but
> I think
> >> it's
> >> >> possible to develop
> >> >> that.
> >> >>
> >> >> Regards Angelo
> >> >>
> >> >> 2010/3/10 Frederik Minatchy<frederik78@yahoo.fr>
> >> >>
> >> >>> Hello...
> >> >>>
> >> >>> Thank you for your answer...
> >> >>>
> >> >>> Your tag seems usefull.. but it seems
> to have
> >> been
> >> >> developped for Struts
> >> >>> 1.x
> >> >>>
> >> >>> --- En date de : Mar 9.3.10, Angelo
> zerr<angelo.zerr@gmail.com>
> >> >> a écrit :
> >> >>>
> >> >>>> De: Angelo zerr<angelo.zerr@gmail.com>
> >> >>>> Objet: Re: About the better way
> to
> >> implement a
> >> >> JSP in read/edit mode
> >> >>>> À: "Struts Users Mailing
> List"<user@struts.apache.org>
> >> >>>> Date: Mardi 9 mars 2010, 21h04
> >> >>>> Hi Frederick,
> >> >>>>
> >> >>>> I had created a project about
> this problem
> >> with
> >> >>>> http://formview.sourceforge.net/
> >> >>>>
> >> >>>> With FormView, you develop ONE
> Jsp to
> >> manage CRUD
> >> >> form.
> >> >>>> It's old project but
> >> >>>> it works well (I have not time
> today to
> >> improve
> >> >> it).
> >> >>>>
> >> >>>> Regards Angelo
> >> >>>>
> >> >>>> 2010/3/9 Paweł Wielgus<poulwiel@gmail.com>
> >> >>>>
> >> >>>>> Hi Frederick,
> >> >>>>> You can also add readonly or
> disabled
> >> >> property to
> >> >>>> textfields.
> >> >>>>> But i don't think that there
> is a
> >> simple
> >> >> answear to
> >> >>>> your question
> >> >>>>> about if it is good or bad.
> >> >>>>>
> >> >>>>> Best greetings,
> >> >>>>> Paweł Wielgus.
> >> >>>>>
> >> >>>>>
> >> >>>>> 2010/3/9 Frederik
> Minatchy<frederik78@yahoo.fr>:
> >> >>>>>> Hello everybody...
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I wonder about the better
> way to
> >> >> implement a JSP
> >> >>>> which shows the same
> >> >>>>> informations in readonly mode
> and in
> >> >>>> creation/modification mode.
> >> >>>>>>
> >> >>>>>> So I have just designed
> the JSP'
> >> fields
> >> >> with
> >> >>>> s:textfield who can be
> >> >>>>> dynamically shown in readonly
> mode
> >> with
> >> >> special css
> >> >>>> (background:transparent;
> >> >>>>> border:none;...) specified in
> the
> >> action
> >> >> class.
> >> >>>>>>
> >> >>>>>> So the action class sets
> some
> >> >> attributes with
> >> >>>> certains values and than
> >> >>>>> the html stream is generated
> in read
> >> mode or
> >> >> in edit
> >> >>>> mode.
> >> >>>>>>
> >> >>>>>> Is this the good way or
> should I
> >> >> developpe two
> >> >>>> JSP : one in read mode and
> >> >>>>> an other one in edit mode?
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> >> >>>>>> For additional commands,
> e-mail:
> >> user-help@struts.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> >>>>> For additional commands,
> e-mail: user-help@struts.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> >>> For additional commands, e-mail: user-help@struts.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: user-help@struts.apache.org
> >> >
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message