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 <poulw...@gmail.com> a écrit : > De: Paweł Wielgus <poulw...@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 <frederi...@yahoo.fr>: > > many thanks :) > > > > I appreciate your response > > > > > > > > > > --- En date de : Mer 10.3.10, Alex Rodriguez Lopez > <alo...@flordeutopia.pt> > > a écrit : > > > >> De: Alex Rodriguez Lopez <alo...@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.z...@gmail.com> > >> a écrit : > >> > > >> >> De: Angelo zerr<angelo.z...@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<frederi...@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.z...@gmail.com> > >> >> a écrit : > >> >>> > >> >>>> De: Angelo zerr<angelo.z...@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<poulw...@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<frederi...@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-unsubscr...@struts.apache.org > >> >>>>>> For additional commands, > e-mail: > >> user-h...@struts.apache.org > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>> > >> >> > >> > --------------------------------------------------------------------- > >> >>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> >>>>> For additional commands, > e-mail: user-h...@struts.apache.org > >> >>>>> > >> >>>>> > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >> > >> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> >>> For additional commands, e-mail: user-h...@struts.apache.org > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> > For additional commands, e-mail: user-h...@struts.apache.org > >> > > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> For additional commands, e-mail: user-h...@struts.apache.org > >> > >> > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
