Re: Discussion forum software -- open source
I'm not aware of any such forum. But I would vote to convert this "Struts Users Mailing List " to dicussion forum like: http://saloon.javaranch.com It will be more easy to read and keep track of individual posts. Is there any software for reading posts mailed in this mailing list? I use simple Gmail Web UI to read and send posts. Bye, Viki. On 12/27/05, Jonnalagadda, Sumithra <[EMAIL PROTECTED]> wrote: > > Is there a open source "Discussion Forum Software" ?. > Thanks in advance. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: pre-populating form fields when called in edit mode.
Hi,
Having separate Actions for insert, update and delete is better. Your
approch for making SetUpAction is right, but it's better to make separate
JSP's instead of writing if-else logic for headers and other related
messages.
Bye,
Viki.
Note: When u'r done with lesson, please sent in this group. Thank you.
On 12/27/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
>
> I'm going to have a good lesson that will show exactly what you want, but
> until then, if you want a quick preview of the Action class, put it here:
>
> http://www.reumann.net/misc/EmployeeAction.txt
>
> You are following an example where I showed using a separate Action for
> each
> behaviour whereas the link above shows a DispatchAction. It's just a short
> cut for putting related tasks in one action versus using separate actions.
> Regardless, though, let's assume your separate Action approach which is
> just
> fine.
>
> I typically would make a SetUpAction that you would call "before" you
> forwarded to the JSP page where you would be editing the form. So let's
> assume you went to edit the Employee from a link you clicked on, the
> process
> would be...
>
> 1) Click on link, passing something like an employeeID
> 2) link submits to your SetUpAction
> 3) In SetUpAction it checks the Request to see if an "employeeID" was
> passed
> to it. If ti was, you go database get your Employee object (EmployeeDTO
> following your old example) and then you can use BeanUtils like you did
> before...
> BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings
> you
> to the "employeForm.jsp" page.
> 4) employeeForm is now all set up with the employee information and
> clicking
> 'submit' would bring you to an UpdateEmployeeAction to do the actual
> update
> (just like you did for the InsertEmployeeAction).
>
> You can easily reuse the form for doing both "inserts" and "updates."
> Typically you'll have to do a little bti of logic for some of the verbage
> to
> decide what to display (ie is header "Insert Employee" or "Update
> Employee"). You can base your logic to decide what to display on various
> things (in this case it could be as simple as looking for an "employeeID"
> ..
> if you have one then you know you are doing an update... if you don't than
> you are doing an insert, but of course there are plenty of other ways to
> do
> it as well.
>
> On 12/25/05, Vikrama Sanjeeva <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Here is the sequence:
> >
> > 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> > radio
> > buttons, text area's and dropdowns.
> > 2: On pressing "Submit" button in "employeeForm.jsp",
> > "InsertEmployeeAction"
> > is called which do the following:
> >
> > 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> > 2.2) DataBaseService.insertEmployee (employeeDTO)
> > 2.3) return mapping.findForward("success");
> >
> > Now, I want to call same "employeeForm.jsp" in "editable" mode, such
> that
> > all the fields (text fields, radio buttons, text area's and dropdowns)
> are
> > "pre-populated". What approaches are there to achieve this? I'm looking
> > for
> > a way which uses same BeanUtils.copyProperties() and copy the
> employeeDTO
> > to employeeForm (Bean). Something like this:
> >
> > When user click's "Edit Employee Form" link, an action
> > (EditEmployeeAction) will be called. Which will do the following:
> >
> > 1. Fetch the employee information from database in employeeDTO.
> > 2. Get the "handle" of EmployeeForm (ActionForm), lets say
> "employeeForm"
> > 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> > 4. return mapping.findForward("editMode");
> >
> > I'm not sure whether this approach will work or not? And whether I
> have
> > to
> > make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode
> (
> > employeeFormEdit.jsp). If this the case, then I guess, I've to make
> > EmployeeFormEdit.java (ActionForm) as well.
> >
> > It will be great if anybody could help me here.
> >
> > Thanks in advance.
> >
> > Bye,
> > Viki.
> >
> >
>
>
> --
> Rick
>
>
Re: pre-populating form fields when called in edit mode.
On 12/26/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > >>I would use the Request for such a List and wouldn't even bother putting > it in the ActionForm > > But that of course doesn't make the list persist. Most frameworks heavily > rely on the user session > and I am now a strong believer that's the better way of doing things. I think it depends on the kind of list and each person may have their own preference. For example, I personally would reather persist on the backend with iBATIS or hibernate vs just stuffing things in the Session. For example, what if it's just one form that needs the list and the user only hits the form one time during the whole time using the site? You've now just just stuff a list in Session scope for what gain? If it's a list that actually will *never* change than put in Application scope. I don't see the point of putting most lists in Session scope. For struts apps most people end up stuffing lists in Session scope so that if validation fails their lists persists on the page. I don't call the validate method manually so I don't run into this problem. Also remember we are talking about "lists" here. Don't think I'm against the Session (if you do a mailing list search you'll see I love the Session maybe too much:) If I remember correctly, I know you promoted a solution of using the > validate() method of > containing those populated lists. That's on the right track but I think a > misuse of the validate() > method. Actually you are remembering incorrectly:) I'm assuming you are referring to this article http://reumann.net/struts/articles/request_lists.jsp, but there I stated exactly the OPPOSITE - that you SHOULD NOT use the validate method for setting up those lists. I said I "do validation manually." I did show how you can simply call the form's validate method manually (even though I don't even go that far in my own apps), but I never mentioned it's a good idea to set up lists in your validate method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that > is called > before executing mostly everything else. JSF is great at handling all of this as well so don't leave JSF out. I try to keep my ActionForm with 'only' properties that the user can edit - > nothing more. > > Ah! You and I really chatted this up a year ago. I was gung-ho for > this method, but no longer. > I was a very die hard proponent of this but I could only go so far with > it; the problem was it > made no logical sense to contain some data in the form (which was then put > into the request) and > then some data in the request. Both end up in the request, so why separate > the two? It did not > allow me to encapsulate my data --- and it created a very difficult > nightmare to track down which > request attributes were appropriate for a given form. So in response, I > concluded this method was > good up to a point, but everything in the action form suited more complex > cases. Well think about it this way, JSF has it right in that it eliminates the need for an ActionForm. It let's you use your regular Value objects which I think is great (I hate the Struts ActionForm:). JSF gets around the Lists problem, though, by taking a whole different model approach which has been talked about enough on the list here but I do like how JSF handles this. (That being said, there are some things I have found frustrating using JSF(MyFaces) so I'm not ready to jump ship yet.) What > seemed like a good solution back then turned out to be the best at that > time; now I think > everything in the form is a better performing car. I only have one "prep" method in my Action so anything that needs to get setup in a form goes in that one place and can be called from the other dispatch methods in the Action. I like the approach since it is easy to maintain. I don't really see what putting the Lists in your ActionForm gains you? You are still going to have to populate them from method calls to other backend objects. Even then, I would think you'd want to use a prep method for that as well since you might need to prep those lists in your form from several dispatch methods. I'm not so sure how doing... form.setSomeList(list) gains you anything over request.setAttribute(Constants.SOME_LIST, someList ); especially if both types of setting is done from a centralized place in your Action. Then again, I'm of course not saying it's bad or wrong to put the stuff in the ActionForm (I even like approaches where nest your value object in the ActionForm). Overall though, I'm just not a fan of having to be stuck using ActionForms in the first place, so I try to avoid as much dependency on them as possible (I really do like the managed bean approach of JSF which handles this stuff so nicely). -- Rick
Re: pre-populating form fields when called in edit mode.
>>ActionForm should be removed from session manually, this is the price to pay. >>I thought about automating this, but Hubert pointed out that a user can open several browser windows for one app, so I gave up on this. One of the biggest concerns I had too was that using the session means only one form can exist per session. So if the user had multiple windows open, it would completely mess things up. So I was for 2 years against making any forms in the session -- until Tapestry woke me up =) It is now my opinion that any complex web app form will have BO, DTOs, and lists all together. This merits only ONE of these being editable at once. Got multiple windows open? Sorry user, but you're not going to be able to use my app. Spring Framework's Web Flow is an excellent plugin for these situations; it allows multiple flows until the first one wins. I just had to accept the fact that until Struts allows forms to exist on a per-view basis, the best a complex app can do is limit one form to the session. Simple forms can be request based, but anything editable (and worthwhile to the customer) definitely has to be session. Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I guess it is not surprising that I would do a completely orthogonal thing ;-) ActionForm is an I/O buffer, it aggregates BO/DTO + lists/options for selectboxes + error messages for the aggregated BO. BO exposes properties that are editable and "persistable". BO does not care about option lists because actual BO or database row contains only one value. BO is a nested property within session-scoped ActionForm. Whenever error is made and page is reloaded, or a user just navigates a page, it displays BO in its current state and associated messages. ActionForm should be removed from session manually, this is the price to pay. I thought about automating this, but Hubert pointed out that a user can open several browser windows for one app, so I gave up on this. Storing list in the session (session-scoped ActionForm, poteito-potahto) also helps in case the option list itself was changed down on the business/persistent level, so a new instance in request would not match previous one, and current selection would get screwed up. Actually, if the option list is changed very rarely, I'd put it into app context. If it is changed more frequently, then into session scope, to isolate user session from potential changes. Michael. On 12/26/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > I would use the Request for such a List and wouldn't even bother putting it > in the ActionForm (unless of course the list is something the user is > actually editing, then yes, you'd add that List as an ActionForm property). > I try to keep my ActionForm with 'only' properties that the user can edit - > nothing more. So for example if you were displaying a list of favorite cars > for the user to pick from I would just put that list in the Request and the > "selectedCar" would be the property you would concern youself with in the > ActionForm. (If you are worried about performance, I'd put the performance > concerns on the backend.. let the back end take care of any list caching.) > > On 12/26/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > > I am going to ask a related question... so take your best shot :-) > > > > I have an edit form in which I have to load a list from the database. The > > list is actually based > > on locale. What's the best solution here? I am using real action forms - > > not that dynafluff stuff > > ;) Is it to simply make my form session scope and attach the list to my > > form? > > > > THANKS! > > Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
>>I would use the Request for such a List and wouldn't even bother putting it >>in the ActionForm But that of course doesn't make the list persist. Most frameworks heavily rely on the user session and I am now a strong believer that's the better way of doing things. I wonder if allowing the developer to be concerned with page/request/session/application scope creates a whole problem in itself; this problem is so unique to Struts and JSP development, but not a thought with Tapestry or JSF. If I remember correctly, I know you promoted a solution of using the validate() method of containing those populated lists. That's on the right track but I think a misuse of the validate() method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that is called before executing mostly everything else. I would like to see this ported into 1.3 because with the ComposableRequestProcessor, you can slam in any cool customization into the processing chain! I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. Ah! You and I really chatted this up a year ago. I was gung-ho for this method, but no longer. I was a very die hard proponent of this but I could only go so far with it; the problem was it made no logical sense to contain some data in the form (which was then put into the request) and then some data in the request. Both end up in the request, so why separate the two? It did not allow me to encapsulate my data --- and it created a very difficult nightmare to track down which request attributes were appropriate for a given form. So in response, I concluded this method was good up to a point, but everything in the action form suited more complex cases. This is my opinion based on experience. Sometimes I just have to travel down the road far enough to see how far the solution will take me -- some solutions are 20 gallon cars, others 30, 50. What seemed like a good solution back then turned out to be the best at that time; now I think everything in the form is a better performing car. Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I would use the Request for such a List and wouldn't even bother putting it in the ActionForm (unless of course the list is something the user is actually editing, then yes, you'd add that List as an ActionForm property). I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. So for example if you were displaying a list of favorite cars for the user to pick from I would just put that list in the Request and the "selectedCar" would be the property you would concern youself with in the ActionForm. (If you are worried about performance, I'd put the performance concerns on the backend.. let the back end take care of any list caching.) On 12/26/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > I am going to ask a related question... so take your best shot :-) > > I have an edit form in which I have to load a list from the database. The > list is actually based > on locale. What's the best solution here? I am using real action forms - > not that dynafluff stuff > ;) Is it to simply make my form session scope and attach the list to my > form? > > THANKS! > Paul > > > > > __ > Yahoo! for Good - Make a difference this year. > http://brand.yahoo.com/cybergivingweek2005/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Rick
Discussion forum software -- open source
Is there a open source "Discussion Forum Software" ?. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I am going to ask a related question... so take your best shot :-) I have an edit form in which I have to load a list from the database. The list is actually based on locale. What's the best solution here? I am using real action forms - not that dynafluff stuff ;) Is it to simply make my form session scope and attach the list to my form? THANKS! Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
If you treat inserts like updates, things get much easier. When you
show employee in edit mode, just pull his data from database into
BO/DTO and show it. When you add new employee, create a new empty
BO/DTO first. Then show it just like you would do it in edit mode. If
user clicks "Save", insert data. If user cancels, just dispose the
object, this is it.
Michael J.
On 12/25/05, Vikrama Sanjeeva <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Here is the sequence:
>
> 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> radio
> buttons, text area's and dropdowns.
> 2: On pressing "Submit" button in "employeeForm.jsp",
> "InsertEmployeeAction"
> is called which do the following:
>
> 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> 2.2) DataBaseService.insertEmployee (employeeDTO)
> 2.3) return mapping.findForward("success");
>
> Now, I want to call same "employeeForm.jsp" in "editable" mode, such that
> all the fields (text fields, radio buttons, text area's and dropdowns) are
> "pre-populated". What approaches are there to achieve this? I'm looking
> for
> a way which uses same BeanUtils.copyProperties() and copy the employeeDTO
> to employeeForm (Bean). Something like this:
>
> When user click's "Edit Employee Form" link, an action
> (EditEmployeeAction) will be called. Which will do the following:
>
> 1. Fetch the employee information from database in employeeDTO.
> 2. Get the "handle" of EmployeeForm (ActionForm), lets say "employeeForm"
> 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> 4. return mapping.findForward("editMode");
>
> I'm not sure whether this approach will work or not? And whether I have
> to
> make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode (
> employeeFormEdit.jsp). If this the case, then I guess, I've to make
> EmployeeFormEdit.java (ActionForm) as well.
>
> It will be great if anybody could help me here.
>
> Thanks in advance.
>
> Bye,
> Viki.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tabs is struts
Oops, the live demo uses old tag classes and works in Ajax mode only now. Have to redeploy the app, should take an hour or so. On 12/26/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > It is possible to have both types of functionality (with full page > reload and with asynchronous request) in just one component. Check > this out, does it look like something you need: > http://www.superinterface.com/jspcontrols/tabcontrol/index.jsp > > If you have modern browser that supports XMLHTTPRequest and has > Javascript turned on, the tab panels will be reloaded using In-Place > Update (Ajax). If you have Javascript turned off or you have, say > Netscape 4, then the page will be refreshed. Notice that this would be > a redirect, not a forward, so you can refresh it manually after that > with no warnings. Also, with redirect you get the same user > experience, because page locations are not piled in browser page > history. > > The tabs in the demo were created using JSP Controls Tag Library: > http://jspcontrols.sourceforge.net/ > > Michael J. > > >From: Yujun Liang <[EMAIL PROTECTED]> > >Reply-To: "Struts Users Mailing List" > >To: Struts Users Mailing List > >Subject: Re: tabs is struts > >Date: Fri, 9 Dec 2005 09:02:42 +1100 > > > >On web page, there are two kinds of tabs, > >1. Tab-looking pages with the different style for active tab, there is > >nothing special for this kind of tab, you can just treat them as the POHA > >(Plain Old HTML Application), well you need design the styles. Please check > >CSS-2 document. Page refresh will be observed for tab switch. > >2. DHTML Tabs, this is dynamic and you won't see page refresh, it is really > >like the POWA(Plain Old Windows Application), to achieve this, you may need > >hidden frames for data transmission or you can use AJAX. > > > >If you client can afford to use JavaScript, the option 2 is definitely a > >preferred choice, it gives the user real time experience. > >If the application has to be W3C Accessibility complaint, you have no > >choice > >to use option 1. So the tab is just a different look and feel, not really > >different from other kind of page. From one example of Struts Recipe by > >George Franciscus, I can tell the Tabs generated by Struts Layout Tag are > >JavaScript driven so it is not W3C Accessibility complaint. > > > >Regards > > > >On 12/8/05, Raghu Kanchustambham <[EMAIL PROTECTED]> wrote: > > > > > > Try struts layout tags. > > > They support tabbed inputs. > > > > > > > > > > > > On 12/8/05, Sony Thomas <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > Is there is any way to use tabs in struts. Is there is any html bean > > > tag for this ? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tabs is struts
It is possible to have both types of functionality (with full page reload and with asynchronous request) in just one component. Check this out, does it look like something you need: http://www.superinterface.com/jspcontrols/tabcontrol/index.jsp If you have modern browser that supports XMLHTTPRequest and has Javascript turned on, the tab panels will be reloaded using In-Place Update (Ajax). If you have Javascript turned off or you have, say Netscape 4, then the page will be refreshed. Notice that this would be a redirect, not a forward, so you can refresh it manually after that with no warnings. Also, with redirect you get the same user experience, because page locations are not piled in browser page history. The tabs in the demo were created using JSP Controls Tag Library: http://jspcontrols.sourceforge.net/ Michael J. >From: Yujun Liang <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" >To: Struts Users Mailing List >Subject: Re: tabs is struts >Date: Fri, 9 Dec 2005 09:02:42 +1100 > >On web page, there are two kinds of tabs, >1. Tab-looking pages with the different style for active tab, there is >nothing special for this kind of tab, you can just treat them as the POHA >(Plain Old HTML Application), well you need design the styles. Please check >CSS-2 document. Page refresh will be observed for tab switch. >2. DHTML Tabs, this is dynamic and you won't see page refresh, it is really >like the POWA(Plain Old Windows Application), to achieve this, you may need >hidden frames for data transmission or you can use AJAX. > >If you client can afford to use JavaScript, the option 2 is definitely a >preferred choice, it gives the user real time experience. >If the application has to be W3C Accessibility complaint, you have no >choice >to use option 1. So the tab is just a different look and feel, not really >different from other kind of page. From one example of Struts Recipe by >George Franciscus, I can tell the Tabs generated by Struts Layout Tag are >JavaScript driven so it is not W3C Accessibility complaint. > >Regards > >On 12/8/05, Raghu Kanchustambham <[EMAIL PROTECTED]> wrote: > > > > Try struts layout tags. > > They support tabbed inputs. > > > > > > > > On 12/8/05, Sony Thomas <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Is there is any way to use tabs in struts. Is there is any html bean > > tag for this ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] JSP Controls Tag Library 0.2 is released
(1) New features * Hidden field in component HTML form is no more needed * It is possible to update several components in Ajax mode * The transition between Ajax and non-Ajax mode is undetectable, you can switch Javascript support on or off and see no visual difference. * It is possible to set target location in Reload tag. * Mini Blogger showcase sample * Tab control sample, see the live demo. Notice how the page is updated in Ajax and non-Ajax modes. Home page: http://jspcontrols.sourceforge.net/ Demos: http://www.superinterface.com/jspcontrols (2) Informecial JSP Controls Tag Library provides the lifecycle for portlet-like JSP components. The Library does not require a portal engine or other central controller. The components built with the Library can be employed in any application that uses JSP, including Struts applications. The Library utilizes two request processing concepts: * Traditional synchronous HTTP request/response cycle (Non-Ajax mode), and * In-place updating for browsers supporting XMLHTTPRequest object (Ajax mode). Input and output are treated as two distinct phases. On input phase (or accept phase) a browser sends an event and accompanying data to a component, usually by submitting an HTML form. On output phase (or render phase) the component displays a view matching its state. By default, in non-Ajax mode each phase corresponds to a separate HTTP request. On input phase browser submits data to a component, and component accepts and processes it. After that, the component reloads the page by redirecting browser to original page location. In Ajax mode an application renders a view directly in response to asynchronous input event, no reloading is needed. An HTML fragment, returned by component, is inserted into the larger composite page without full page refresh. Pages composed with JSP Controls Tag Library look and behave the same way whether they run in Ajax mode or not. In fact, a browser that renders web page in an off-screen buffer, may deliver the same flicker-free experience in non-Ajax mode as other browsers do in Ajax mode. Michael J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I'm going to have a good lesson that will show exactly what you want, but
until then, if you want a quick preview of the Action class, put it here:
http://www.reumann.net/misc/EmployeeAction.txt
You are following an example where I showed using a separate Action for each
behaviour whereas the link above shows a DispatchAction. It's just a short
cut for putting related tasks in one action versus using separate actions.
Regardless, though, let's assume your separate Action approach which is just
fine.
I typically would make a SetUpAction that you would call "before" you
forwarded to the JSP page where you would be editing the form. So let's
assume you went to edit the Employee from a link you clicked on, the process
would be...
1) Click on link, passing something like an employeeID
2) link submits to your SetUpAction
3) In SetUpAction it checks the Request to see if an "employeeID" was passed
to it. If ti was, you go database get your Employee object (EmployeeDTO
following your old example) and then you can use BeanUtils like you did
before...
BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings you
to the "employeForm.jsp" page.
4) employeeForm is now all set up with the employee information and clicking
'submit' would bring you to an UpdateEmployeeAction to do the actual update
(just like you did for the InsertEmployeeAction).
You can easily reuse the form for doing both "inserts" and "updates."
Typically you'll have to do a little bti of logic for some of the verbage to
decide what to display (ie is header "Insert Employee" or "Update
Employee"). You can base your logic to decide what to display on various
things (in this case it could be as simple as looking for an "employeeID" ..
if you have one then you know you are doing an update... if you don't than
you are doing an insert, but of course there are plenty of other ways to do
it as well.
On 12/25/05, Vikrama Sanjeeva <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Here is the sequence:
>
> 1: User fill up's "employeeForm.jsp" which have multiple text fields,
> radio
> buttons, text area's and dropdowns.
> 2: On pressing "Submit" button in "employeeForm.jsp",
> "InsertEmployeeAction"
> is called which do the following:
>
> 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm)
> 2.2) DataBaseService.insertEmployee (employeeDTO)
> 2.3) return mapping.findForward("success");
>
> Now, I want to call same "employeeForm.jsp" in "editable" mode, such that
> all the fields (text fields, radio buttons, text area's and dropdowns) are
> "pre-populated". What approaches are there to achieve this? I'm looking
> for
> a way which uses same BeanUtils.copyProperties() and copy the employeeDTO
> to employeeForm (Bean). Something like this:
>
> When user click's "Edit Employee Form" link, an action
> (EditEmployeeAction) will be called. Which will do the following:
>
> 1. Fetch the employee information from database in employeeDTO.
> 2. Get the "handle" of EmployeeForm (ActionForm), lets say "employeeForm"
> 3. BeanUtils.copyProperties(employeeForm, employeeDTO)
> 4. return mapping.findForward("editMode");
>
> I'm not sure whether this approach will work or not? And whether I have
> to
> make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode (
> employeeFormEdit.jsp). If this the case, then I guess, I've to make
> EmployeeFormEdit.java (ActionForm) as well.
>
> It will be great if anybody could help me here.
>
> Thanks in advance.
>
> Bye,
> Viki.
>
>
--
Rick
Re: custom server side validation in shale
On 12/26/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > it would be nice if Commons Validator > would read more than one resource bundle file without needing to extract it > and add the file to WEB-INF/classes yourself I think it already does. :) Looking at CommonsValidator.getErrorMessage again, it first looks in the application's message bundle, and then looks in oas.validator/messages.properties. Assuming you've defined your message bundle in faces-config.xml: ApplicationResources ... You can add your custom messages to (in this case) WEB-INF/classes/ApplicationResources.properties, and leave messages.properties alone. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what is diffrent between Struts Datasource and Tomcat datasource
On 12/26/05, Legolas Woodland <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote: > > On 12/26/05, Legolas Woodland <[EMAIL PROTECTED]> wrote: > > > >> Hi > >> thank you for reading my post. > >> we can define data-source inside Struts-config.xml > >> also it is possible to define a data-source in tomcat admin page. > >> no my question is : > >> what is differences between them , are they the same ? > >> Which requirement each of this data-source has ? > >> > > > > > > >From the simplest possible perspective, one could say that the two data > > sources are pretty much equivalent ... they both provide you with a > > connection pool for sharing a small number of JDBC connections (to the > same > > underlying database) across all the incoming requests of your > application, > > without requiring you to allocate a request per user, even when that > user > > does not have an active request. > > > > In terms of recommended usage, though, you are strongly encouraged *not* > to > > use the Struts version ... use the connection pool provided by your > servlet > > container instead. Struts 1.0 included the data source implementation > > because, at the time, most servlet containers had no such support. Now > that > > they all do, the Struts data source support was deprecated in 1.1, and > > removed in 1.2. > > > > Craig > > > > > > Thank you for reply. > If i want to use Tomcat Data-source , tomcat must have my jdbc driver in > its shared lib folder (is it true?) See the Tomcat documentation for precise requirements. For example, if you're using 5.5: http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html if i do not use struts data-source , i it possible to use tomcat > data-source without having access to change tomcat specific settings ? > i mean : is it possible to include the data-source inside the war file > descriptors ? for example web.xml , or context.xml ? > *if im not mistaken we can put a context.xml inside meta-inf folder > which will act like server context definition. You can indeed do this (if your Tomcat environment is configured appropriately): http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html Your best bet on getting detailed help would be to ask questions about it on the Tomcat user mailing list (to subscribe, send an empty message to < [EMAIL PROTECTED]>). Craig
Re: what is diffrent between Struts Datasource and Tomcat datasource
Craig McClanahan wrote: On 12/26/05, Legolas Woodland <[EMAIL PROTECTED]> wrote: Hi thank you for reading my post. we can define data-source inside Struts-config.xml also it is possible to define a data-source in tomcat admin page. no my question is : what is differences between them , are they the same ? Which requirement each of this data-source has ? >From the simplest possible perspective, one could say that the two data sources are pretty much equivalent ... they both provide you with a connection pool for sharing a small number of JDBC connections (to the same underlying database) across all the incoming requests of your application, without requiring you to allocate a request per user, even when that user does not have an active request. In terms of recommended usage, though, you are strongly encouraged *not* to use the Struts version ... use the connection pool provided by your servlet container instead. Struts 1.0 included the data source implementation because, at the time, most servlet containers had no such support. Now that they all do, the Struts data source support was deprecated in 1.1, and removed in 1.2. Craig Thank you for reply. If i want to use Tomcat Data-source , tomcat must have my jdbc driver in its shared lib folder (is it true?) if i do not use struts data-source , i it possible to use tomcat data-source without having access to change tomcat specific settings ? i mean : is it possible to include the data-source inside the war file descriptors ? for example web.xml , or context.xml ? *if im not mistaken we can put a context.xml inside meta-inf folder which will act like server context definition. Thank you again for reply. * Thank you
Re: what is diffrent between Struts Datasource and Tomcat datasource
On 12/26/05, Legolas Woodland <[EMAIL PROTECTED]> wrote: > > Hi > thank you for reading my post. > we can define data-source inside Struts-config.xml > also it is possible to define a data-source in tomcat admin page. > no my question is : > what is differences between them , are they the same ? > Which requirement each of this data-source has ? >From the simplest possible perspective, one could say that the two data sources are pretty much equivalent ... they both provide you with a connection pool for sharing a small number of JDBC connections (to the same underlying database) across all the incoming requests of your application, without requiring you to allocate a request per user, even when that user does not have an active request. In terms of recommended usage, though, you are strongly encouraged *not* to use the Struts version ... use the connection pool provided by your servlet container instead. Struts 1.0 included the data source implementation because, at the time, most servlet containers had no such support. Now that they all do, the Struts data source support was deprecated in 1.1, and removed in 1.2. Craig Thank you > >
what is diffrent between Struts Datasource and Tomcat datasource
Hi thank you for reading my post. we can define data-source inside Struts-config.xml also it is possible to define a data-source in tomcat admin page. no my question is : what is differences between them , are they the same ? Which requirement each of this data-source has ? Thank you
Re: custom server side validation in shale
On 12/26/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>
> On 12/22/05, JEEVANATHAM P. /BPCRP/INFOTECH/VASHI
> <[EMAIL PROTECTED]> wrote:
>
> > Please let me know about how can we do server side validation in shale.
> Like
> > user validation,
> >
> > when user enters some value that time we need to check with database
> whether
> > that is correct one or not.
>
> This is an interesting question because I have a custom validator in a
> Struts app that does exactly that. Here's what I came up with, though
> I would advise waiting for Craig to comment on whether he intended for
> this to happen. :)
>
> I added another to validator-rules.xml:
>
> classname="net.wsmoak.acctmtce.ValidationUtil"
> method="isDate"
> methodParams="java.lang.String"
> msg="errors.lenientDate">
>
>
> The ValidationUtil.isDate method takes a String and returns true/false
> (boolean).
>
> Left to its own devices, oas.validatorCommonsValidator uses the
> (localized) messages.properties file in org.apache.struts.validator
> (inside shale-core.jar). Since I know the Servlet spec requires that
> things in WEB-INF/classes be loaded before things in WEB-INF/lib, I
> extracted the messages.properties file from shale-core.jar, to
> WEB-INF/classes/org/apache/shale/validator/, and added my new message
> to it.
>
> In the JSP:
>
>
>value="#{effectiveDate}">
> type="lenientDate"
> server="true"
> client="false"/>
>
>
>
> At least for simple validations, it appears to work fine. It has
> advantages over all of the 'pure JSF' methods that I investigated-- I
> certainly don't want to write a custom Validator, and even a simple
> method binding in the 'validator' attribute of a component means
> you're responsible for formatting the error message. But if you need
> more/different parameters than the ones provides,
> then I do think you'd need to write your own custom JSF Validator and
> tag, or possibly extend the ones in Shale.
>
> I'm going to open a couple of enhancement tickets for things like
> including validator-rules.xml in shale-core.jar so that you don't have
> to find and include a copy in your webapp to use the provided
> validators, and making the the name and location of both the messages
> and the validation rules file(s) configurable. Other ideas and
> suggestions are welcome!
Wendy's technique works fine, although it would be nice if Commons Validator
would read more than one resource bundle file without needing to extract it
and add the file to WEB-INF/classes yourself (your reading of the ordering
requirements is correct).
As for doing things in pure JSF validators (either a separate Validator
implementation or as a validation method pointed to with a method binding),
Shale does offer some help for formatting the messages. There are two
classes in the org.apache.shale.util package for this purpose:
* LoadBundle - Loads a resource bundle and exposes it as a Map (similar
in spirit to what the tag does in a page, but making the
messages available programatically as well.
* Messages - Utillity for getting locale-specific messages from a set of
resource bundles, including parameter substitution, similar to what
Struts Action Framework provides with MessageResources.
Both of these classes are pure POJOs designed to be configured with setter
injection, so it is very easy to configure them as managed beans (normally
in application scope). See the class level javadocs of these two classes
for examples.
HTH,
> --
> Wendy
> http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleValidator
Craig
Re: custom server side validation in shale
On 12/22/05, JEEVANATHAM P. /BPCRP/INFOTECH/VASHI <[EMAIL PROTECTED]> wrote: > Please let me know about how can we do server side validation in shale. Like > user validation, > > when user enters some value that time we need to check with database whether > that is correct one or not. This is an interesting question because I have a custom validator in a Struts app that does exactly that. Here's what I came up with, though I would advise waiting for Craig to comment on whether he intended for this to happen. :) I added another to validator-rules.xml: The ValidationUtil.isDate method takes a String and returns true/false (boolean). Left to its own devices, oas.validatorCommonsValidator uses the (localized) messages.properties file in org.apache.struts.validator (inside shale-core.jar). Since I know the Servlet spec requires that things in WEB-INF/classes be loaded before things in WEB-INF/lib, I extracted the messages.properties file from shale-core.jar, to WEB-INF/classes/org/apache/shale/validator/, and added my new message to it. In the JSP: At least for simple validations, it appears to work fine. It has advantages over all of the 'pure JSF' methods that I investigated-- I certainly don't want to write a custom Validator, and even a simple method binding in the 'validator' attribute of a component means you're responsible for formatting the error message. But if you need more/different parameters than the ones provides, then I do think you'd need to write your own custom JSF Validator and tag, or possibly extend the ones in Shale. I'm going to open a couple of enhancement tickets for things like including validator-rules.xml in shale-core.jar so that you don't have to find and include a copy in your webapp to use the provided validators, and making the the name and location of both the messages and the validation rules file(s) configurable. Other ideas and suggestions are welcome! HTH, -- Wendy http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleValidator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
