You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kade Jeevan Kumar <je...@yahoo.com> on 2005/08/25 14:09:37 UTC
A concern about object maintenance with Struts Framework
Hi All!
I am new to Struts and i am impressed with the framework, its INTENDED concept.
But i went through the Struts implementation in one of my project i came to know there are some of the real time issues are there as mentioned below;
1) Object Maintenance
2) Time of debugging
3) Dynamically added form component
OBJECT MAINTENANCE
When i went through implementing Struts for my project it really sucks as the number of objects for each functionality is excedded as each functionality in my project is totally differ from other functionalities.
what is your concern about Object Maintenance. Is there any better way for object maintenance.
TIME OF DEBUGGING
Whenever if i get any exception due to lack of co-ordination between my JSP form and ActionForm the error messages are not in a proper debuggable way. Sometimes, if something goes wrong with the code it doesn't intimate me with proper error message, but common to all errors it gives me "bean-util exception"
If i want to fix the needed error in any of the JSP i need to go through struts-config.xml, tiles-def.xml, and then get the related JSP and then fix it out.
DYNAMICALLY ADDED FORM COMPONENT
In one of my screen, i came across a need of adding the form components dynamically using javascript (dynamically adding chek boxes). what is the solution offered by struts to hold this situation to read the data into the ActionForm.
I know, that am a newbe for Struts, but when i went through the Forms and many Search Engines i failed to get the Proper information or Solution. But i hope and believe that there should be ways to deal these situations, if Yes please let me Know.
Regards
Jeevan Kumar. Kade
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: A concern about object maintenance with Struts Framework
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
> OBJECT MAINTENANCE
>
> When i went through implementing Struts for my project it really sucks as the number of objects for each functionality is excedded as each functionality in my project is totally differ from other functionalities.
>
> what is your concern about Object Maintenance. Is there any better way for object maintenance.
There are ways that you can use to reduce the number of Struts objects
in your application. For instance, DispatchAction and its subclasses,
as well as ActionDispatcher, can help your combine related Action
classes. For form beans, you can take a look at dynamic forms that
don't require you to declare a class at all.
DispatchAction (also check its Direct Known Subclasses):
http://struts.apache.org/api/org/apache/struts/actions/DispatchAction.html
ActionDispatcher:
http://struts.apache.org/api/org/apache/struts/actions/ActionDispatcher.html
DynaActionForm classes:
http://struts.apache.org/userGuide/building_controller.html#dyna_action_form_classes
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamically adding checkboxes (was: A concern about...)
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
>
> In one of my screen, i came across a need of adding the form components dynamically using javascript (dynamically adding chek boxes). what is the solution offered by struts to hold this situation to read the data into the ActionForm.
>
> I know, that am a newbe for Struts, but when i went through the Forms and many Search Engines i failed to get the Proper information or Solution. But i hope and believe that there should be ways to deal these situations, if Yes please let me Know.
I've seen this topic come up a few times already on the user list. I
suggest going through the mail archives and running your searches
through those. http://struts.apache.org/mail.html#archives
Also, check the wiki. Maybe someone has already posted a how-to over
there: http://wiki.apache.org/struts/. If you don't find anything
there, but discover how to later on, perhaps you can share it by
posting it on there. :)
Hubert
User list tip: Letting your msg subject reflect your msg body could
get you more "eyes" and better responses. For instance, someone not
wanting to concern themselves about "object maintenance" would totally
miss your question on dynamically adding form elements.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/25/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'll revisit the work I've already done one of these days and share my
> observations.
...but don't let me keep you from working on this! If you have the
itch then by all means go ahead and take it on!
Hubert
>
> On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
> > One small thing we could do is go through everywhere there is a
> > SAXException caught and add code to specifically catch a
> > SAXParseException and use the several properties of that type to
> > provide considerably more information than we do now.
> > SAXParseException can tell you exactly the file name (system ID),
> > line number and column where a syntax error occurred. This could
> > help a lot when debugging config file problems.
> >
> > Similarly, there are other places where we throw through exceptions
> > from underlying Commons libraries where we could strategically catch
> > common exceptions which throw people (like a lookup exception for an
> > <html:form> tag) and wrap them with contextual information based on
> > years of experience.
> >
> > It's hard, because when you've been doing this for a while, you can
> > forget how you learned to decode some of the messages -- but I've
> > been helping a few people get up to speed on Struts again recently
> > and it has brought some of this to the foreground.
> >
> > Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
>
> I'm sure that's part of it -- but in my book, even just telling
> people which file has the problem would help a lot; at least, in my
> case, where we make a myriad of config files to make things easier to
> manage. There are also probably just rules of XML such that the
> parser may legitimately consider the problem to be someplace other
> than where you do -- but it would still be better than nothing.
>
> And the other thing, were we could add context and experience to
> "interpret" exceptions thrown from libraries instead of just passing
> them through or lightly wrapping them -- that could do a huge amount
> for usability.
>
> Joe
Agreed. While I was disappointed in what I saw with my casual tests,
my thought then was to share my findings and see (1) where it could be
improved, and (2) which parts we deem valuable and helpful enough to
incorporate.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:20 PM -0500 8/25/05, Hubert Rabago wrote:
>(Moving to dev.)
>
>I already started to take a look at this sometime ago. (In fact, I
>had to make sure I didn't check in changes I shouldn't while I was
>working on those deprecations.) The thing I ran into was, the result
>I'd get wasn't always fully reliable. If a forward of an action had a
>problem, for instance, the line number I'd get would sometimes be the
>one where the closing </action-mappings> tag was at.
>
>It may be that the reliability of the line number we get would depend
>on the SAX parser implementation in use.
I'm sure that's part of it -- but in my book, even just telling
people which file has the problem would help a lot; at least, in my
case, where we make a myriad of config files to make things easier to
manage. There are also probably just rules of XML such that the
parser may legitimately consider the problem to be someplace other
than where you do -- but it would still be better than nothing.
And the other thing, were we could add context and experience to
"interpret" exceptions thrown from libraries instead of just passing
them through or lightly wrapping them -- that could do a huge amount
for usability.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Hubert Rabago <hr...@gmail.com>.
(Moving to dev.)
I already started to take a look at this sometime ago. (In fact, I
had to make sure I didn't check in changes I shouldn't while I was
working on those deprecations.) The thing I ran into was, the result
I'd get wasn't always fully reliable. If a forward of an action had a
problem, for instance, the line number I'd get would sometimes be the
one where the closing </action-mappings> tag was at.
It may be that the reliability of the line number we get would depend
on the SAX parser implementation in use.
I'll revisit the work I've already done one of these days and share my
observations.
Hubert
On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
> One small thing we could do is go through everywhere there is a
> SAXException caught and add code to specifically catch a
> SAXParseException and use the several properties of that type to
> provide considerably more information than we do now.
> SAXParseException can tell you exactly the file name (system ID),
> line number and column where a syntax error occurred. This could
> help a lot when debugging config file problems.
>
> Similarly, there are other places where we throw through exceptions
> from underlying Commons libraries where we could strategically catch
> common exceptions which throw people (like a lookup exception for an
> <html:form> tag) and wrap them with contextual information based on
> years of experience.
>
> It's hard, because when you've been doing this for a while, you can
> forget how you learned to decode some of the messages -- but I've
> been helping a few people get up to speed on Struts again recently
> and it has brought some of this to the foreground.
>
> Joe
>
>
>
>
> At 9:22 AM -0500 8/25/05, Hubert Rabago wrote:
> >On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
> >>
> >> Whenever if i get any exception due to lack of co-ordination
> >>between my JSP form and ActionForm the error messages are not in a
> >>proper debuggable way. Sometimes, if something goes wrong with the
> >>code it doesn't intimate me with proper error message, but common
> >>to all errors it gives me "bean-util exception"
> >>
> >> If i want to fix the needed error in any of the JSP i need to go
> >>through struts-config.xml, tiles-def.xml, and then get the related
> >>JSP and then fix it out.
> >>
> >
> >There's a good chance that you'll encounter this same situation with
> >any framework that uses XML config files. However, I agree (and I'm
> >not the only committer that does) that Struts can do a better job
> >providing information when something goes wrong (like, say, which
> >action forward it couldn't find). I've made some tiny changes to
> >provide more information about an error condition in some situations,
> >but for the most part, I'd have to wait until somebody reports
> >something in particular before I'll know where to look. I've been
> >looking at the situations reported in
> >http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 and the issues
> >that were linked to it in one way or another. (Now all I need is a
> >bit more free time.) If you encounter something in particular that
> >you think Struts can do something about, file an enhancement request.
> >And if you could, some patches as well. :) Actually, I really
> >wouldn't mind test cases I can use, or even a very small zip
> >containing files I can use to recreate the error (and help me verify
> >I've fixed it). Sometimes the time consuming part is writing the
> >sample app to show me I'm done.
> >
> >Hubert
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Joe Germuska <Jo...@Germuska.com>.
One small thing we could do is go through everywhere there is a
SAXException caught and add code to specifically catch a
SAXParseException and use the several properties of that type to
provide considerably more information than we do now.
SAXParseException can tell you exactly the file name (system ID),
line number and column where a syntax error occurred. This could
help a lot when debugging config file problems.
Similarly, there are other places where we throw through exceptions
from underlying Commons libraries where we could strategically catch
common exceptions which throw people (like a lookup exception for an
<html:form> tag) and wrap them with contextual information based on
years of experience.
It's hard, because when you've been doing this for a while, you can
forget how you learned to decode some of the messages -- but I've
been helping a few people get up to speed on Struts again recently
and it has brought some of this to the foreground.
Joe
At 9:22 AM -0500 8/25/05, Hubert Rabago wrote:
>On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
>>
>> Whenever if i get any exception due to lack of co-ordination
>>between my JSP form and ActionForm the error messages are not in a
>>proper debuggable way. Sometimes, if something goes wrong with the
>>code it doesn't intimate me with proper error message, but common
>>to all errors it gives me "bean-util exception"
>>
>> If i want to fix the needed error in any of the JSP i need to go
>>through struts-config.xml, tiles-def.xml, and then get the related
>>JSP and then fix it out.
>>
>
>There's a good chance that you'll encounter this same situation with
>any framework that uses XML config files. However, I agree (and I'm
>not the only committer that does) that Struts can do a better job
>providing information when something goes wrong (like, say, which
>action forward it couldn't find). I've made some tiny changes to
>provide more information about an error condition in some situations,
>but for the most part, I'd have to wait until somebody reports
>something in particular before I'll know where to look. I've been
>looking at the situations reported in
>http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 and the issues
>that were linked to it in one way or another. (Now all I need is a
>bit more free time.) If you encounter something in particular that
>you think Struts can do something about, file an enhancement request.
>And if you could, some patches as well. :) Actually, I really
>wouldn't mind test cases I can use, or even a very small zip
>containing files I can use to recreate the error (and help me verify
>I've fixed it). Sometimes the time consuming part is writing the
>sample app to show me I'm done.
>
>Hubert
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Error info (was: A concern about object maint...)
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
>
> Whenever if i get any exception due to lack of co-ordination between my JSP form and ActionForm the error messages are not in a proper debuggable way. Sometimes, if something goes wrong with the code it doesn't intimate me with proper error message, but common to all errors it gives me "bean-util exception"
>
> If i want to fix the needed error in any of the JSP i need to go through struts-config.xml, tiles-def.xml, and then get the related JSP and then fix it out.
>
There's a good chance that you'll encounter this same situation with
any framework that uses XML config files. However, I agree (and I'm
not the only committer that does) that Struts can do a better job
providing information when something goes wrong (like, say, which
action forward it couldn't find). I've made some tiny changes to
provide more information about an error condition in some situations,
but for the most part, I'd have to wait until somebody reports
something in particular before I'll know where to look. I've been
looking at the situations reported in
http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 and the issues
that were linked to it in one way or another. (Now all I need is a
bit more free time.) If you encounter something in particular that
you think Struts can do something about, file an enhancement request.
And if you could, some patches as well. :) Actually, I really
wouldn't mind test cases I can use, or even a very small zip
containing files I can use to recreate the error (and help me verify
I've fixed it). Sometimes the time consuming part is writing the
sample app to show me I'm done.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org