Excel download
Hi all, Is there any way in struts to download the page (view part) in Excel format. Thanks & Regards, SenthilRajan VS
Re: Using struts forms as Value Objects: your opinion?
On 7/12/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi Craig > > I understand that you did not follow this thread from the beginning. > As I mentioned before - when working with int, short, byte types - my > app works fine. I don't get any runtime exception! > If you are not getting an exception in this case (an ActionForm of type "int", bound to a text field on the input form, and the user types "1a3"), then you must be doing something other than the simple description I provided. Or, you must be violating another important principle (if the user types "1a3" in an integer field, you should redisplay the page with an appropriate error message *and* the "1a3" should be there for the user to fix. > Is it crucial for the Action Form to have String properties? > Five years of history with Struts (and I should know, since I created it originally) says "yes" :-) > Rivka Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload/download file to/from oracle blob field with struts
Frank, I found a solution for it. Thanks, "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: I had to do this for an application. While the code is fairly lengthy, longer than I'd like to post here, if you come up against specific problems feel free to ping me. Although I didn't look at the article Martin referenced for you, it's a fairly generic problem, not something that you will write a bunch of Oracle-specific code for (I suppose you *could*, but at least when I did it I did not, and it was straight JDBC coding). Frank EROL TEZCAN wrote: > Hi, > > I want to upload/download a file to/from oracle blob field. > > How can I do this ? > > Please give an example code. > > Thanks, > > Erol > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Sell on Yahoo! Auctions - No fees. Bid on great items.
Re: Putting execute() in ActionForm
On 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > Very few had the idea of passing ActionForm as VO to persistence > layer. This is some kind of backwards MVC. Contrary, the idea was to > use BOs in ActionForm with session scope, thus making it a stateful > interactive business object. Haven't been around the Struts mailing list for five years, have you? :-) > > I am not sold on the idea that presentation should have state. Why? > Presentation presents. Business objects have data and state. If I > aggregate BO into view, I do not break classic MVC design. Instead, I > gain in terms that I have my data in one place instead of two places. > This is classic database rule: if you can have data in one place, have > it there. This saves from discrepancies and is easier to maintain, to > understand and to follow the relationships. > I'll give you one trivial example where view state matters ... lots of applications have a way to select the language in which the user wishes to interact, which should also affect things like date and currency formats. It is ridiculous for the application developer to have to manually set such a property on every request ... that's what frameworks do (and, to their credit, frameworks like Struts and JSF deal with this quite nicely). But it is a *view* tier piece of state, and has nothing to do with the model tier. There are other examples (which columns in a table are you sorting on? Have you applied any filters? Is this tree node expanded or collapsed?) but the point is clear ... there is indeed such a thing as view tier state that is totally independent of model tier state. > Treeviews may contain business data, or may not, so I see value of > having things like treeviews in view layer. Comboboxes are usually not > a business data, busines data is only one value from this combobox. > Regular data that comes from database and edited by user, is busines > data, and it is much easier to pull it from a real BO and to display > it. > So, are you saying that a tree view should *not* remember which nodes are opened and closed? > > The JSF recommended pattern actually lets you do "dispatch action" > > sorts of things, but a bit more easily :-). > > JSF isolates business data from widgetse even further. Also, JSF is > not advertised as framework where a resource returns different views. > Instead, it is advertised as Page Controller, which works well for > former desktop programmers, but does not fit HTTP ideology. Not that > it is not possible to emulate Front Controller in JSF, but it takes > some tricks for that. > > Same goes for ASP.NET - easy to develop, clumsy to use. Of course, > Microsoft provided option to not use _viewstate, but everybody uses > it, because it is used in sample code and is considered standard. I am > glad that JSF stores viewstate on server by default, this is much > better. Why should *JSF* be required to play the front controller role you describe, when the servlet API provides clearly adequate features if that is what you want to do? That suggestion reminds me of one of my first exposures to "frameworks" a couple decades ago ... Microsoft's MFC framework for writing Windows apps. If you could craft your requirements in terms of the APIs that MFC provided, you were going to be OK ... but woe be you if you wanted to go outside the framework! Modern frameworks should be fine grained and composable ... combine the pieces you need in order to accomplish your application requirements. You, as an application developer, should *not* be forced into "my way or the highway" decisions simply because the developers of your framework did not anticipate your particular use case. After all, why would anyone care about formalized "dispatch actions" in a Struts environment? You know the answer ... the basic framework doesn't know how to deal with the complexities of this use case. You've found a nice answer, but it's constrained by trying to be compatible with Struts 1.x. That's a *perfectly* reasonable goal, if that is what you are after -- that's just not where I am now. Where I am, it's a much simpler problem if you remove that constraint. The exact same design principles can be expressed much more elegantly if you don't need to worry about implementing Action or ActionForm. > > Michael. > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
Nitish Kumar wrote:
"This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:("
good point, but where do I register my custom converters? I dont want to do
it in my action classes, and writing a plugin just to register my converters
would be a big overhead.
Writing a plugin is quite easy and takes not more than 10 minutes. So
don't affraid and try it :-) , if you'd like I can share some code here.
I have only one plugin which I use only for this purpose - to init some
special libraries like BeanUitils converter, Hibernate Session Factory etc.
It's very usefull, becuase I don't like the usual practice to make
inizializations in static scope of the clases (because the sequence of
these static initializations can vary run time)
Why cant we have declative registration through struts-config.xml, just like
other components and struts should take care of registering my converters
with ConvertUtil? (If its not already done yet!)
This would actually give me flexibility to have my custom types as well in
the form bean.
Lets say, for some application I want all java.util.Long types to be
appended with "$" symbol, it becomes much easier with a converter.
what do you say?
this is good point, as I saw Craig McClanahan also likes the idea ...
probably the development team will embrace it.
Regards
Borsilav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi Craig I understand that you did not follow this thread from the beginning. As I mentioned before - when working with int, short, byte types - my app works fine. I don't get any runtime exception! Is it crucial for the Action Form to have String properties? Rivka -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 8:06 AM To: Struts Users Mailing List Subject: Re: Using struts forms as Value Objects: your opinion? On 7/11/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi guys, > > Borislav - thank you for the time you spent debugging this issue :-) > > So now I wonder - is it o.k. to use typed properties in my Action Forms? > Or is there an important reason why I should Strings only? > To answer this question for yourself, please build a trivial Struts based application like this: * Build a form bean that has a property of type "int". * Build a JSP page with a form that binds this property to a text input field. * Deploy the application, and type "1a3" instead of "123" into that field. If you like the result (a runtime exception), then by all means go ahead and make your action form properties be typed. Otherwise, if you're going to use Struts you should listen to all the tutorials and books and articles and mailing list messages that tell you to make your form bean properties be strings :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Borislav Sabev <[EMAIL PROTECTED]> wrote: > Rick Reumann wrote: > > > > > You shouldn't want a "default" at all provided by BeanUtils for cases > > where it can be null! You are using the anomoly of the way Integer is > > working and wanting to propogate that poor solution. null should be > > null.. it shouldn't be 0 or some default Date if null is provided. > > > Yes, this is the strange point. So null value doesn't have the same > semantic for Integer, Double etc. and Date, so I find this a bit > confusing ...this means at least different approach in handling the > incorrect values in forms. Blame backwards compatibility. By the time this issue was raised, there were huge numbers of applications already dependent on the previous behavior, which would have been broken by a change. However, this shouldn't have *any* impact on "incorrect values in forms". If you are following the recommended design pattern of using String fields in your form beans, it shouldn't trouble you. > > > If you want a default Date or some other default than provide that > > before going to your form...or if after it submits and you see a null, > > then provide the default. You could of course register your own > > converter to provide a default for when a Date is null- but I would > > NOT do this. > > I thought about such variant but I don't find it good as well, but may > be this is the less harmful or let's say less painful. > Dates and Times and Timestamps were *deliberately* omitted from the default set of conversions performed by BeanUtils. The reason is simple ... such conversions are Locale specific, and BeanUtils has not concept (in its standard APIs at least) of what a "Locale" is. You can use the converters in "org.apache.beanutils.locale" for dealing with this sort of thing, but that came later than the basic Struts architecture. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I think of the state information represented by an ActionForm (in > Struts 1.x) or potentially as properties of an "action" class (per the > current discussion) to be part of the *view* tier. Further, I see the > role of the execute method on an action as being an Adapter Pattern > link between the web tier (HTTP-centric) and the model tier > (HTTP-agnostic). Therefore, I don't feel any pain at the idea of > combining the two together. > > The primary mistake to avoid is using an ActionForm as a VO passed to > your persistence tier. This seems a little less likely when the same > object has behavior as well as data, but you still need to watch out > for this. Very few had the idea of passing ActionForm as VO to persistence layer. This is some kind of backwards MVC. Contrary, the idea was to use BOs in ActionForm with session scope, thus making it a stateful interactive business object. I am not sold on the idea that presentation should have state. Why? Presentation presents. Business objects have data and state. If I aggregate BO into view, I do not break classic MVC design. Instead, I gain in terms that I have my data in one place instead of two places. This is classic database rule: if you can have data in one place, have it there. This saves from discrepancies and is easier to maintain, to understand and to follow the relationships. Treeviews may contain business data, or may not, so I see value of having things like treeviews in view layer. Comboboxes are usually not a business data, busines data is only one value from this combobox. Regular data that comes from database and edited by user, is busines data, and it is much easier to pull it from a real BO and to display it. > The JSF recommended pattern actually lets you do "dispatch action" > sorts of things, but a bit more easily :-). JSF isolates business data from widgetse even further. Also, JSF is not advertised as framework where a resource returns different views. Instead, it is advertised as Page Controller, which works well for former desktop programmers, but does not fit HTTP ideology. Not that it is not possible to emulate Front Controller in JSF, but it takes some tricks for that. Same goes for ASP.NET - easy to develop, clumsy to use. Of course, Microsoft provided option to not use _viewstate, but everybody uses it, because it is used in sample code and is considered standard. I am glad that JSF stores viewstate on server by default, this is much better. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: You shouldn't want a "default" at all provided by BeanUtils for cases where it can be null! You are using the anomoly of the way Integer is working and wanting to propogate that poor solution. null should be null.. it shouldn't be 0 or some default Date if null is provided. Yes, this is the strange point. So null value doesn't have the same semantic for Integer, Double etc. and Date, so I find this a bit confusing ...this means at least different approach in handling the incorrect values in forms. If you want a default Date or some other default than provide that before going to your form...or if after it submits and you see a null, then provide the default. You could of course register your own converter to provide a default for when a Date is null- but I would NOT do this. I thought about such variant but I don't find it good as well, but may be this is the less harmful or let's say less painful. Actually, in regards to a Date, in case you didn't already realize, you'll have to provide your own converter anyway if you plan to use java.util.Date since BeanUtils doesn't provide that by default.. it only provides conversion for java.sql.Date. If you need help with the converters I can post some code or search the struts archives for "java.util.Date converter" I found this as well, which was other surpise. (that java.sql.Date is not supported directly). Other confusing is that if you use ConvertUtils to convert back from Date to String (so you can show it in the jsp) it doesn't use the format that is loaded by the converter. This problem again force me to have the format string at least in 2 places: once in the converter that I register in ConvertUtils, and once in my formatter that I use to display the date values. Thus, you are encouraged to use the forms primary as input forms, not as output (but there is a survey among Struts developers how they use the forms, and more than 50% use them for input and output) IMHO this a "inconsistency" and force us to make a lot of additional workarounds and tricks... Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi guys, > > Borislav - thank you for the time you spent debugging this issue :-) > > So now I wonder - is it o.k. to use typed properties in my Action Forms? > Or is there an important reason why I should Strings only? > To answer this question for yourself, please build a trivial Struts based application like this: * Build a form bean that has a property of type "int". * Build a JSP page with a form that binds this property to a text input field. * Deploy the application, and type "1a3" instead of "123" into that field. If you like the result (a runtime exception), then by all means go ahead and make your action form properties be typed. Otherwise, if you're going to use Struts you should listen to all the tutorials and books and articles and mailing list messages that tell you to make your form bean properties be strings :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
On 7/11/05, Nitish Kumar <[EMAIL PROTECTED]> wrote:
>
> "This is a HUGE problem with BeanUtils and why I end up having to
> register custom converters:("
>
> good point, but where do I register my custom converters? I dont want to do
> it in my action classes, and writing a plugin just to register my converters
> would be a big overhead.
>
I guess I have a pretty hard time understanding why this is a "big
overhead". Writing a Struts plugin is about the same amount of effort
as writing a ServletContextListener implementation to do the same
thing (which is the better approach if you're on a Servlet 2.3 or
later container).
But, the key point is that either way it's a pretty simple method
declaration, plus one line of code for each converter you want to
register.
> Why cant we have declative registration through struts-config.xml, just like
> other components and struts should take care of registering my converters
> with ConvertUtil? (If its not already done yet!)
>
> This would actually give me flexibility to have my custom types as well in
> the form bean.
>
> Lets say, for some application I want all java.util.Long types to be
> appended with "$" symbol, it becomes much easier with a converter.
>
> what do you say?
>
That's certainly possible to implement ... and I'm sure the Struts
developer community would consider an RFE plus a patch to make it
possible. But, to me personally, this isn't the highest possible
return you can get from using a framework, so it wouldn't surprise me
if the Struts developers focused on different areas first.
In the mean time, if you want to get any attention to this issue, the
starting point would be to file an RFE in the issue tracking system
.
> Thanks and Regards,
> Nitish Kumar
>
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote:
> > There are reasons to have an "application scoped" front controller.
> > There are reasons to have a "view-scoped" front controller. There is
> > *no* reason I am aware of that requires these controllers to be the
> > same :-).
>
> Good point. In fact, I don't think it would take much to convince me
> that it's better if they ARE NOT the same :)
>
> > In Shale, the application-scoped functions are performed by a Commons
> > Chain pipeline that is configured and processed by Shale's filter.
> > This is the right place to put things like "if the user isn't logged
> > on, redirect to the login page" and "log every request" type
> > functions. But it is not the right place for "execute this expensive
> > SQL query, but *only* if I am the view that needs it.".
>
> This sounds very much like the types of things I would typically do in a
> filter. I'm a fan of filters because it's one less piece of the
> puzzle that doesn't tie me to a particular framework (I've done some
> converting of apps from one framework to another, so I always keep the
> possibility in mind as much as possible).
>
> Is there a benefit to the Chain approach over filters?
>
In this case, the only purpose of the Shale application filter is to
execute a Chain that is applied to all requests. So have it your way
:-).
Seriously, the reason for that choice was to reduce the amount of
effort needed to add a particular piece of application scope logic.
It's a lot easier for a newbie to implement a Command, and then add it
to a configured chain, without having to understand the whole
processing flow of a Filter. The only tricky bit is whether to return
true or false from the execute() method :-).
On the other hand, use of the Shale application filter does *not*
preclude you from using other technologies (like securityfilter) that
are also based on filters. One of the key lessons I've learned is
that frameworks should be fine grained, not monolithic ... make it
*easy* for your users to incorporate additional capabilities. Filters
are a huge enabling technology that are free for the taking if you
assume a Servlet 2.3 or later baseline (as Shale does, but as Struts
1.x has not as yet). So, if you like filters, go for it ... they'll
work fine in a Shale environment.
> > In Struts 1.x, you get around the latter case, typically, by having a
> > setup action before the view, and a process action after the view.
> > Shale simply combines those two bits of code into a single class (and,
> > along the way, combining the form bean too), resulting in a little
> > less code, but a lot fewer classes.
>
> I think I just realized why I'm not completely excited by this... I've
> never been a fan of DispatchAction, and while I understand it isn't
> exactly analogous, it is along the same lines.
>
> You couldn't know just how ironic me saying that is, but trust me, it is
> :) Probably 6 or 7 years back I had some rather heated debates with
> some coworkers where I was trying to convince them it was better to have
> a single class with a switch block than a couple of individual classes
> (this was before frameworks were en vogue, so we were talking servlet
> design). I've done a complete 180 on that, to the point where I,
> generally, won't use DispatchAction.
>
> It was, until now when I realized it, giving me a subconscious dislike
> of anything along those lines :)
>
The JSF recommended pattern actually lets you do "dispatch action"
sorts of things, but a bit more easily :-). The key is that you can
bind different submit buttons to different execution methods ("action"
methods in JSF terminology) -- and those methods can either be in the
same class or in different classes. Both have nice advantages:
* If you have a search widget on every page of your app, you can
bind all of them to a single common action that performs the search.
Coupled with outcome-based navigation, the developer implementing
the search functionality doesn't have to care anything about navigation --
his or her only job is to report back on what happened (for a search
widget, typical results would be "no matches", "one match", or "multiple
matches" ... which the application architect can map to a single view,
two views, or three views at his or her whim -- *without* changing any code.
* If you have, say, an "Update" button at both the top and the bottom
of a long table, you can bind them to the same action, since you want
exactly the same behavior -- you are only providing two ways to invoke
it as a convenience to the user (GMail users will instantly recognize this
as the paradigm that is used for the "Newer" and "Older" buttons in the
index view).
> > People do that with form beans already, so we clearly haven't
> > succeeded in communicating the correct pattern :-).
>
> Agreed. And I for one cannot claim to have always gotten it right either :)
>
> >
RE: Using struts forms as Value Objects: your opinion?
Hi guys,
Borislav - thank you for the time you spent debugging this issue :-)
So now I wonder - is it o.k. to use typed properties in my Action Forms?
Or is there an important reason why I should Strings only?
I don't add my Action Form properties to the Struts config file. Is it
o.k. - or am I missing something here?
Thanks
Rivka
-Original Message-
From: Borislav Sabev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 7:38 PM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Nitish Kumar wrote:
>I think raghavendra is right.
>Rivka, your code is working because you are using primitive type int
and not
>the wrapper type Integer.
>In case of primitive type in case of any exception, it gives you a
default
>value.
>
>
>Thanks and Regards,
>Nitish Kumar
>
>
>
>
So after small debugging session I found why it works for Integers and
not for dates (at least in my case)
all classes that implment Convertors interface in BeanUtils, have
something like this as implementation of convert() method:
public Object convert(Class type, Object value) {
if (value == null) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException("No value specified");
}
}
if (value instanceof Date) {
return (value);
}
try {
return (Date.valueOf(value.toString()));
} catch (Exception e) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException(e);
}
}
}
In case of the Integer there is pre-load default value and EVEN if
conversion fails during the population phase, it just use is the dafault
value (and you think it's parsed correctly). In the previous example its
a coincidence that Rivka have 0 as default value (it's just the same
value as init value of IntegerConverter).
The strange point is that I didn't find how can I set a default date
value ... if someone knows it, please share this knowledge here.
For sure this is not a big discovery, but I spent a lot of hours to
udnerstand it and I though that this should be described somewhere at
some public place ... that's why I was a bit bitter in my previuos posts
Regards
Borislav
**
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or
the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content. **
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
"This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:("
good point, but where do I register my custom converters? I dont want to do
it in my action classes, and writing a plugin just to register my converters
would be a big overhead.
Why cant we have declative registration through struts-config.xml, just like
other components and struts should take care of registering my converters
with ConvertUtil? (If its not already done yet!)
This would actually give me flexibility to have my custom types as well in
the form bean.
Lets say, for some application I want all java.util.Long types to be
appended with "$" symbol, it becomes much easier with a converter.
what do you say?
Thanks and Regards,
Nitish Kumar
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 11:17 PM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Borislav Sabev wrote the following on 7/11/2005 1:37 PM:
> In case of the Integer there is pre-load default value and EVEN if
> conversion fails during the population phase, it just use is the dafault
> value (and you think it's parsed correctly). In the previous example its
> a coincidence that Rivka have 0 as default value (it's just the same
> value as init value of IntegerConverter).
Bingo:) Sorry saw this thread late and could have helped out much
sooner. This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:(
BeanUtils (at least it always has done this, maybe in a recent version
it's hopefully changed?), will end up converting null values to 0!!
Stupid, stupid if you ask me (null means null not 0!) Goes the same for
the other numeric wrappers as well. (I think their argument was for
backwards compatibility with apps that expect that behavior).
In regard to you point...
> The strange point is that I didn't find how can I set a default date
> value ... if someone knows it, please share this knowledge here.
You shouldn't want a "default" at all provided by BeanUtils for cases
where it can be null! You are using the anomoly of the way Integer is
working and wanting to propogate that poor solution. null should be
null.. it shouldn't be 0 or some default Date if null is provided.
If you want a default Date or some other default than provide that
before going to your form...or if after it submits and you see a null,
then provide the default. You could of course register your own
converter to provide a default for when a Date is null- but I would NOT
do this.
Actually, in regards to a Date, in case you didn't already realize,
you'll have to provide your own converter anyway if you plan to use
java.util.Date since BeanUtils doesn't provide that by default.. it only
provides conversion for java.sql.Date. If you need help with the
converters I can post some code or search the struts archives for
"java.util.Date converter"
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
Craig McClanahan wrote: There are reasons to have an "application scoped" front controller. There are reasons to have a "view-scoped" front controller. There is *no* reason I am aware of that requires these controllers to be the same :-). Good point. In fact, I don't think it would take much to convince me that it's better if they ARE NOT the same :) In Shale, the application-scoped functions are performed by a Commons Chain pipeline that is configured and processed by Shale's filter. This is the right place to put things like "if the user isn't logged on, redirect to the login page" and "log every request" type functions. But it is not the right place for "execute this expensive SQL query, but *only* if I am the view that needs it.". This sounds very much like the types of things I would typically do in a filter. I'm a fan of filters because it's one less piece of the puzzle that doesn't tie me to a particular framework (I've done some converting of apps from one framework to another, so I always keep the possibility in mind as much as possible). Is there a benefit to the Chain approach over filters? In Struts 1.x, you get around the latter case, typically, by having a setup action before the view, and a process action after the view. Shale simply combines those two bits of code into a single class (and, along the way, combining the form bean too), resulting in a little less code, but a lot fewer classes. I think I just realized why I'm not completely excited by this... I've never been a fan of DispatchAction, and while I understand it isn't exactly analogous, it is along the same lines. You couldn't know just how ironic me saying that is, but trust me, it is :) Probably 6 or 7 years back I had some rather heated debates with some coworkers where I was trying to convince them it was better to have a single class with a switch block than a couple of individual classes (this was before frameworks were en vogue, so we were talking servlet design). I've done a complete 180 on that, to the point where I, generally, won't use DispatchAction. It was, until now when I realized it, giving me a subconscious dislike of anything along those lines :) People do that with form beans already, so we clearly haven't succeeded in communicating the correct pattern :-). Agreed. And I for one cannot claim to have always gotten it right either :) It's not about mixing layers. It is about mixing all the parts of the *same* tier (view) related to a particular page into a single class, instead of three classes (setup action, form bean, and process action). The adapter has to be somewhere no matter what; co-hosting it in a single class turns out to have benefits in terms of simplicity and unit testability. While I agree on the unit testability point, I'm not completely sold on the simplicity argument... there's always a fine line between how much actual code there is and how big the object hierarchy is. Go too far either way and its complex, just in different ways. Again, I've changed my opinion on this, but I now feel that a larger number of classes, assuming each has a clearly defined role to play, is easier to digest than a single class with all the code, or perhaps even a little more code, in it. Again, there is a bit of a fine line there because if there are too many classes, no matter how simple, it becomes difficult to see how they all fit together. In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a *lot*. In 1.4 JDKs, it basically doesn't matter unless you have *huge* request volumes. Thus, the reasons for most people to not put their adapters in request scope is basically gone. That's good info, thanks! :) I wonder, and I'm not the first one I'm sure, what would it take to make Struts work that way now? More importantly, what would the consequences be? It seems like it could be done in a completely backwards-compatible way, at least at first pass through my brain. Just remember ... the lifetime of Struts 1.x (five years since initial conception, four years since 1.0) is basically a geologic era in terms of Internet time :-). Absolutely! You must have gotten *something* right for Struts to have this kind of staying power :) I can think of many things that seemed like the greatest thing since sliced bread at the time that wound up fading into obscurity in half that time. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > I think of the state information represented by an ActionForm (in > > Struts 1.x) or potentially as properties of an "action" class (per the > > current discussion) to be part of the *view* tier. Further, I see the > > role of the execute method on an action as being an Adapter Pattern > > link between the web tier (HTTP-centric) and the model tier > > (HTTP-agnostic). Therefore, I don't feel any pain at the idea of > > combining the two together. > > It sounds like what your saying is that there really is no need for a > control layer, we're coming down to view-adapter-model now. Am I > understanding that correctly? > Not completely, but amost. There are reasons to have an "application scoped" front controller. There are reasons to have a "view-scoped" front controller. There is *no* reason I am aware of that requires these controllers to be the same :-). In Shale, the application-scoped functions are performed by a Commons Chain pipeline that is configured and processed by Shale's filter. This is the right place to put things like "if the user isn't logged on, redirect to the login page" and "log every request" type functions. But it is not the right place for "execute this expensive SQL query, but *only* if I am the view that needs it.". In Struts 1.x, you get around the latter case, typically, by having a setup action before the view, and a process action after the view. Shale simply combines those two bits of code into a single class (and, along the way, combining the form bean too), resulting in a little less code, but a lot fewer classes. > I absolutely agree that the ActionForm, or properties of Action, is > indeed part of the view. And, as per your next paragraph, I absolutely > agree we shouldn't be passing that state information, in either form, > directly to the model. > > So, in my mind, if we are talking about a single class that has > properties of the view layer, as well as an adapter to the model in > execute() (which we may or may not still call the control layer I > suppose), that feels like co-mingling two tiers, something we have > always convinced ourselves is a bad idea. > See above. > Further, what would stop something from stretching a bit further and > saying that DTOs from the control to the model should be in the form of > maybe an inner class in the Action, further co-mingling in the model > tier, arguably? > People do that with form beans already, so we clearly haven't succeeded in communicating the correct pattern :-). But, if you do the right thing in Struts 1.x, you already have zero model tier code, or business logic, in your actions -- they are already performing the adapter role. > I'd be very interested to understand why, assuming my interpretation is > correct to begin with, we should start to think differently now about > the mixing of parts of various layers in a single entity. I don't ask > to be confrontational at all by the way, but its an interesting > discussion to me. > It's not about mixing layers. It is about mixing all the parts of the *same* tier (view) related to a particular page into a single class, instead of three classes (setup action, form bean, and process action). The adapter has to be somewhere no matter what; co-hosting it in a single class turns out to have benefits in terms of simplicity and unit testability. WebWork and JSF got this one right. > > The primary mistake to avoid is using an ActionForm as a VO passed to > > your persistence tier. This seems a little less likely when the same > > object has behavior as well as data, but you still need to watch out > > for this. > > Agreed, that is indeed the real problem to avoid in the end. How best > to accomplish it might be debatable, but I think we all agree this is > the gotcha to avoid :) > > > That (combined "action form" and "action" concept) is indeed the > > recommended design pattern when using JSF, as well as with WebWork, > > which uses the same idea. Although it does reduce the total line > > count slightly, this is outweighed, IMHO, by other advantages: > > > > * The input values are available as instance variables in your > > "action" class, which makes coding accesses to those values > > a little simpler (foo instead of formBean.getFoo()). > > That is one benefit I definitely like as well. Although it has never > caused me personally any major heartache that you can't do this with > Struts, I have seen instances where it would have made life a little > simpler. > > > * Because of that, there's a little less per-request object creation > > going on (although you trade that off for the "action" class being > > instantiated per request, so it is almost a push). > > I've always wondered about how big a help it is to not be instantiating > Actions per-request (although I suppose I haven't wondered it enough to > do any benchmarks myself :) ). It always
Re: Putting execute() in ActionForm
Craig McClanahan wrote: I think of the state information represented by an ActionForm (in Struts 1.x) or potentially as properties of an "action" class (per the current discussion) to be part of the *view* tier. Further, I see the role of the execute method on an action as being an Adapter Pattern link between the web tier (HTTP-centric) and the model tier (HTTP-agnostic). Therefore, I don't feel any pain at the idea of combining the two together. It sounds like what your saying is that there really is no need for a control layer, we're coming down to view-adapter-model now. Am I understanding that correctly? I absolutely agree that the ActionForm, or properties of Action, is indeed part of the view. And, as per your next paragraph, I absolutely agree we shouldn't be passing that state information, in either form, directly to the model. So, in my mind, if we are talking about a single class that has properties of the view layer, as well as an adapter to the model in execute() (which we may or may not still call the control layer I suppose), that feels like co-mingling two tiers, something we have always convinced ourselves is a bad idea. Further, what would stop something from stretching a bit further and saying that DTOs from the control to the model should be in the form of maybe an inner class in the Action, further co-mingling in the model tier, arguably? I'd be very interested to understand why, assuming my interpretation is correct to begin with, we should start to think differently now about the mixing of parts of various layers in a single entity. I don't ask to be confrontational at all by the way, but its an interesting discussion to me. The primary mistake to avoid is using an ActionForm as a VO passed to your persistence tier. This seems a little less likely when the same object has behavior as well as data, but you still need to watch out for this. Agreed, that is indeed the real problem to avoid in the end. How best to accomplish it might be debatable, but I think we all agree this is the gotcha to avoid :) That (combined "action form" and "action" concept) is indeed the recommended design pattern when using JSF, as well as with WebWork, which uses the same idea. Although it does reduce the total line count slightly, this is outweighed, IMHO, by other advantages: * The input values are available as instance variables in your "action" class, which makes coding accesses to those values a little simpler (foo instead of formBean.getFoo()). That is one benefit I definitely like as well. Although it has never caused me personally any major heartache that you can't do this with Struts, I have seen instances where it would have made life a little simpler. * Because of that, there's a little less per-request object creation going on (although you trade that off for the "action" class being instantiated per request, so it is almost a push). I've always wondered about how big a help it is to not be instantiating Actions per-request (although I suppose I haven't wondered it enough to do any benchmarks myself :) ). It always seemed perfectly reasonable that it was a benefit, I've never doubted it was, but I've always wondered if it was truly worth the trade-offs. * The code becomes easier to unit test because your test case simply has to instantiate your "action" class, set the appropriate properties, and call the execute() method. Lots less to do setting up mock objects that simulate a servlet container. Indeed, that is a nice benefit. As I've said publicly on more than one occasion, if I'd thought of this approach (action class with properties for the request variables, instantiated per request) early enough, this is what Struts 1.0 would have done. Alas, by the time the value of this pattern became clear, backwards compatibility was an important issue, and we couldn't change. Eh, live and learn. No one gets it right every time out :) And it isn't like you got anything *wrong* per se anyway, you figured out something better later on. The developer that has never had a revelation after the fact is a better developer than any of us for sure! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Most of my validation is handled by the Validator framework right now > which, admitedly, ties things to Struts to some extent (though there's no > reason I couldn't pull Validator 'down' a level and use it under some other > presentation technology if it didn't provide an equivalent. > Indeed, making this possible was a primary reason for separating validator out of Struts and moving it to Jakarta Commons in the first place. This has enabled lots of folks to use Commons Validator for enforcing rules in the business tier (as opposed to the view tier) -- to say nothing of allowing Shale to leverage the client side validation capabilities without depending on Struts 1.x code. > L. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: [snip] > By combining Actions and ActionForms, you are breaking the separation. > There *IS* clearly benefit to doing so... cutting down class count is > something I'm always in favor of, so long as line count doesn't increase > as a result. But is it worth it? I think of the state information represented by an ActionForm (in Struts 1.x) or potentially as properties of an "action" class (per the current discussion) to be part of the *view* tier. Further, I see the role of the execute method on an action as being an Adapter Pattern link between the web tier (HTTP-centric) and the model tier (HTTP-agnostic). Therefore, I don't feel any pain at the idea of combining the two together. The primary mistake to avoid is using an ActionForm as a VO passed to your persistence tier. This seems a little less likely when the same object has behavior as well as data, but you still need to watch out for this. > Clearly some now believe it is... as I understand it, that's one of the > important concepts in JSF and ASP.Net, among others. > I wonder, would you think there is benefit to combining the two over a > declarative approach like DynaActionForm? Using them you cut the class > count down similarly, and in fact *REDUCE* overall line count as well, > and you gain a declarative approach to things, which is definitely nice > (I seem to remember that's how JSF approaches things, but it has been a > while since I looked, my memory may be fooling me). That (combined "action form" and "action" concept) is indeed the recommended design pattern when using JSF, as well as with WebWork, which uses the same idea. Although it does reduce the total line count slightly, this is outweighed, IMHO, by other advantages: * The input values are available as instance variables in your "action" class, which makes coding accesses to those values a little simpler (foo instead of formBean.getFoo()). * Because of that, there's a little less per-request object creation going on (although you trade that off for the "action" class being instantiated per request, so it is almost a push). * At least in the JSF case, the component handles conversions for you, so "foo" can be an int if the value is supposed to be an integer. No more BeanUtils.copyProperties() calls. * The code becomes easier to unit test because your test case simply has to instantiate your "action" class, set the appropriate properties, and call the execute() method. Lots less to do setting up mock objects that simulate a servlet container. As I've said publicly on more than one occasion, if I'd thought of this approach (action class with properties for the request variables, instantiated per request) early enough, this is what Struts 1.0 would have done. Alas, by the time the value of this pattern became clear, backwards compatibility was an important issue, and we couldn't change. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tiles and multipart messages
No, I don't have this problem for the moment! But, I might come across it as the project progresses. Is there anything changing then? In any case, thanks a lot for your help. On 7/11/05, Durham David R Jr Ctr 805 CSPTS/SCE < [EMAIL PROTECTED]> wrote: > > > I suspect my error is that instead of sending the request directly to > > the *Action and then forward - in case of success - to a page > > definition, I tried to send the request to a page definition > > (containing the *Action) and from the *Action forwarding to a > > tile definition. > > > > Do you agree? > > Yes. Are you doing some kind of multi-step process where users upload a > file, then select some menu option, and then complete the process? > > > - Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Validation problem
Thanks, I got it!... I needed to save the errors :) Rick Thanks for ur advice about using another class to manage JDBC... I'll review that... Do u know any samples about how to do that?.. Thanks again -- Rafael Taboada Software Engineer Cell : +511-97753290 "No creo en el destino pues no me gusta tener la idea de controlar mi vida"
Re: Validation problem
On 7/11/05, Rafael Taboada <[EMAIL PROTECTED]> wrote:
> Hi. When I turned off validation yn mi struts-config.xml, validation isn't
> called. And when I turned off validation and call validate manually inside a
> method of my ActionClass, validation isn't called.
> I calle validate method in:
> public ActionForward buscarColor(ActionMapping mapping, ActionForm
> form,HttpServletRequest request, HttpServletResponse response) {
> ...
> colorForm.validate(mapping,request);
> ...
> }
> Maybe I'm calling this validate method in an incorrect way??
Hmm... It should be called. Are you sure that your validate in the
form overrides validate(ActionMapping mapping,
javax.servlet.http.HttpServletRequest request) and not this one
ActionErrors validate(ActionMapping mapping,
javax.servlet.ServletRequest request) ?
Put some debug output into your validate method as well before and
after your call to colorForm.validate(mapping,request), maybe this one
is not called.
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation problem
Rafael Taboada wrote the following on 7/11/2005 5:55 PM:
Hi. When I turned off validation yn mi struts-config.xml, validation isn't
called. And when I turned off validation and call validate manually inside a
method of my ActionClass, validation isn't called.
I calle validate method in:
public ActionForward buscarColor(ActionMapping mapping, ActionForm
form,HttpServletRequest request, HttpServletResponse response) {
...
colorForm.validate(mapping,request);
...
}
Maybe I'm calling this validate method in an incorrect way??
Are you 'sure' it's not being called?
You need get the Errors back that are returned and put them in scope.
Here's an example from my code...
//in your Action ...
ActionErrors errors = colorForm.validate( mapping, request );
if ( errors != null && !errors.isEmpty ) {
saveErrors(request, errors);
setUp(request); //puts some things back in scope that I need
return (mapping.findForward(UIconstants.FAILURE));
}
return (mapping.findForward(UIconstants.SUCCESS));
if ( errors != null && !errors.isEmpty ) <-- this part can probably be
shortened, I was too lazy to figure out what really gets returned if
validation passes.. a null or empty ActionErrors?
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Michael Jouravlev wrote: On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Is not it easier to have one nested VO/BO with string properties, than to copy properties back and forth from action form to VO? I use web framework only to expose my real objects to the outer world. If you don't mind your VOs/BOs being untyped then sure, I guess it's easier. Personally I'd rather use strongly typed interfaces as far as possible. 2) value objects should use typed interfaces to ensure marshaling to and from presentation format (string types) is pushed as far up the application stack as possible. This also enables other, potentially type-aware, presentation / client tiers to be built on top of the same value objects (e.g. for a web-services interface). I think I do not agree with this one. Let's take it as a design requirement that application that we build is a webapp. It potentially can have different interfaces. This would mean, that: * input data is stingified because of HTTP * Struts is not the only front end Just because the transport protocol is HTTP doesn't mean you're only dealing with string data though. If I add a web services layer, I'll want ot talk in terms of domain types. If I want to add some other RPC mechanism the same will be true. Therefore, it is much easier to create BO/VO with dual string/typed interface or with string interface only. It would do validation and conversion to native datatype internally instead of doing it in validate() method. I believen that this is more flexible approach. What are you going to do with your validation code, if you are told to move from Struts to WebWork or Tapestry? I don't see the difference between having dual string/typed properites and having the same thing split between two classes, other than making the one class more confusing and error prone to use. Most of my validation is handled by the Validator framework right now which, admitedly, ties things to Struts to some extent (though there's no reason I couldn't pull Validator 'down' a level and use it under some other presentation technology if it didn't provide an equivalent. L. On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: Form beans are part of the *view* tier, not the model ... their purpose in life is to represent the server side state of the HTML elements on a form, even if that state is invalid (i.e. not currently passing all the validations). That way, you can reproduce what the user typed so he or she can fix it, rather than presenting them with a completely blank screen. (This is why you generally use string fields in a form bean). This is one way to look at things. Another way is to use VO/BO for input/output directly. When I use existing data, I load it into BO and display it. When I modify it, I update BO using its string properties. If I decide to cancel updates, I siply remove the BO from memory, no database changes needed. If I create a new object, I create a new BO and fill it in. Until I persist it, it hangs in the session. If I decide to cancel, then I remove it, and database would not even know that I was about to insert an object. In a component oriented framework like JSF or Tapestry, you don't need to worry about keeping track of this state information ... the components do it for you. JSF still differentiates "real" object (whatever it might be, a real business object or a VO) from visual component data, which I don't like. From my point of view, it is much easier to have an object with an ID, to view/edit it, or to delete it. Therefore, I do not need viewstate for UI components. I only need to store my object somewhere like in session while I work with it. I want my widgets and my view to be as dumb as possible. All data and state that I need is in real objects, I do not need artificial viewstate to duplicate it. I can understand why JSF or ASP.NET went this route with UI objects and viewstate: to abstract from the model/business layer. They do not want to establish a firm contract with business/persistence layer. They do not want to require a certain BO lifecycle or the datatype limitations. But I as a developer find this inconvenient. Web frameworks designers focus on their framework, while I as an application designer, focus on business data, business process and business state. Take ActiveX. There is a contract, there are interfaces, methods and datatypes defined. Just build an object according to the protocol, and you will be able to have design-time interface, runtime interface, everything. Web frameworks do not want to have strict contracts with data layer probabaly to be more flexible. I would take contract over flexibily anytime. Presuming that this is a flexible contract ;-) Michael. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional com
Re: Putting execute() in ActionForm
Schaub, Stephen wrote: What I'm wanting is an explanation of why I should keep the ActionForm class _separate_ from the Action class. It seems to me that this unnecessarily complicates the application design. When a Struts-based app is "properly" architected, the Actions are nothing more than traffic cops... they move data sent from the client along to some "business delegate" where the real work of the application happens. That is their only purpose in life, theoretically. The design that many people follow is that an ActionForm receives input from the client. The Action receives the form and uses BeanUtils (or similar) to copy the properties of the ActionForm into some other type of bean (DTO) that the business delegate knows how to handle. This is generally done with a single line of code (the copy I mean). Then the appropriate delgate is called, passed that bean, does its thing, and returns the bean (or a different one in some cases). The Action then copies that bean into the ActionForm, again with a single line of code, and forwards as appropriate. There might be some branching based on exceptions the delegate may throw, but in general this is how it flows. So we're talking about three lines of code per Action, in an ideal situation. But that's not the pertinent fact... the pertinent fact is that the Action doesn't know anything about what actually is in the ActionForm, and therefore what is in the view, nor does it know what the delegate does or anything about the bean it uses, or in other words, the model. So, let's imagine a situation where you want to add some fields that a user can enter on a given screen. No problem... you alter only your ActionForm (or just struts-config if your using DynaActionForm), and presumably the bean that gets passed to the delagate class as well. But the important point is that the Action is unchanged because it's only playing its role as a traffic cop and nothing else. By combining Actions and ActionForms, you are breaking the separation. There *IS* clearly benefit to doing so... cutting down class count is something I'm always in favor of, so long as line count doesn't increase as a result. But is it worth it? Clearly some now believe it is... as I understand it, that's one of the important concepts in JSF and ASP.Net, among others. I wonder, would you think there is benefit to combining the two over a declarative approach like DynaActionForm? Using them you cut the class count down similarly, and in fact *REDUCE* overall line count as well, and you gain a declarative approach to things, which is definitely nice (I seem to remember that's how JSF approaches things, but it has been a while since I looked, my memory may be fooling me). -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation problem
Hi. When I turned off validation yn mi struts-config.xml, validation isn't
called. And when I turned off validation and call validate manually inside a
method of my ActionClass, validation isn't called.
I calle validate method in:
public ActionForward buscarColor(ActionMapping mapping, ActionForm
form,HttpServletRequest request, HttpServletResponse response) {
...
colorForm.validate(mapping,request);
...
}
Maybe I'm calling this validate method in an incorrect way??
--
Rafael Taboada
Software Engineer
Cell : +511-97753290
"No creo en el destino pues no me gusta tener la idea de controlar mi vida"
Re: Validation problem
Rafael Taboada wrote the following on 7/11/2005 5:34 PM:
Michael, it didn't work..
What didn't work? You still got validation when it was set to false?
(Also just a side note, it's good practice to move all the JDBC
Connection stuff to another class other than your Action. You might be
intending to do that later, so not meaning to critique too soon.)
My Action class is:
public class ColorAction extends DispatchAction {
public ActionForward buscarColor(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
ColorForm colorForm = (ColorForm) form;
MySQLDAOFactory factory = new MySQLDAOFactory();
DataSource ds = getDataSource(request,Constantes.DATASOURCEKEY);
Connection conn = ds.getConnection();
Collection collResultado;
try {
ColorDAO colorDAO = factory.getColorDAO(conn);
colorForm.validate(mapping,request);
collResultado = colorDAO.findColorByDescripcion(
colorForm.getstrFiltroDescripcion());
}
finally {
conn.close();
}
colorForm.setlstResultado(collResultado);
return mapping.getInputForward();
}
... //There are other methods
}
So, what is wrong
I tried to use ValidatorActionForm instead of ValidatorForm... And of course
in my validator call my actionmapping like: "/Colores",
"/Colores?method=buscarColor"... But it doesn't work too...
How can I do???... THanks in advance...
When I turned off validate attribute... It doesn't validate anything... I'm
calling validate method in my action class but it doesn't work...
Where are you calling validate manually? I don't see you doing that in
the Action class you provided.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: Unacceptable Behaviour of Mark Galbreath
Or a duck? -Original Message- From: Dave Newton [mailto:[EMAIL PROTECTED] Sent: 11 July 2005 21:34 To: Struts Users Mailing List Subject: Re: [OT] Re: Unacceptable Behaviour of Mark Galbreath Dakota Jack wrote: >You know what a "canard" is Newton? > > Front control surface on an airplane? Really, these questions are too easy. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
I don't see how enabling BO/VO to read stringified data makes them dependant on Struts packages. On 7/8/05, Bill Schneider <[EMAIL PROTECTED]> wrote: > Well put. To expand on #2, it's good to confine dependencies on the > org.apache.struts packages to the presentation layer, and not build a > Struts dependency into business logic. > > > Personally I prefer to keep form beans and value objects seperate, for > > two key reasons: > > > > 1) form beans generally should consist of String data to facilitate > > round-tripping of invalid inputs. I like to constrain them to a clearly > > defined role of marshaling data 'into' and 'out of' the presentation > > layer, i.e. across the boundary between presentation and application. > > > > 2) value objects should use typed interfaces to ensure marshaling to and > > from presentation format (string types) is pushed as far up the > > application stack as possible. This also enables other, potentially > > type-aware, presentation / client tiers to be built on top of the same > > value objects (e.g. for a web-services interface). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Yeah, that's a fair point, it is a bit more documenting than it probably
could be... then again, all modern IDEs will do it for you, right? And
I even have my UltraEdit macros to do it. Still, fair point.
Having not looked into it very much, does annotations in 1.5 help at all
in this regard I wonder?
Frank
Michael Jouravlev wrote:
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
A bean is self-documenting in that you can immediately tell what its
attributes are and what types they are. I'm not even talking about
generating javadoc from the source either, but that's certainly a very
nice by-product.
If I could have a property in Delphi or C# style... Or if I could at
least write something like that:
/**
* Flag that demo mode is on
*/
private boolean isDemo;
public boolean getIsDemo() { ... }
public setIsDemo(boolean isDemo) { ... }
... and my methods *would be commented in javadoc* too, it would be
much better than current approach with lots of lines and comments for
each getter/setter. Three properties commented in current approved
Java style, and you already lost in the code. This sucks.
Michael.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation problem
Michael, it didn't work..
My ActionMapping is:
My ActionForm is:
public class ColorForm extends ValidatorForm {
private String strFiltroDescripcion;
private List lstResultado;
private String idColor;
private String strDescripcion;
private String[] chkColores;
... // Each attribute has its getter and setter
}
My Action class is:
public class ColorAction extends DispatchAction {
public ActionForward buscarColor(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
ColorForm colorForm = (ColorForm) form;
MySQLDAOFactory factory = new MySQLDAOFactory();
DataSource ds = getDataSource(request,Constantes.DATASOURCEKEY);
Connection conn = ds.getConnection();
Collection collResultado;
try {
ColorDAO colorDAO = factory.getColorDAO(conn);
colorForm.validate(mapping,request);
collResultado = colorDAO.findColorByDescripcion(
colorForm.getstrFiltroDescripcion());
}
finally {
conn.close();
}
colorForm.setlstResultado(collResultado);
return mapping.getInputForward();
}
... //There are other methods
}
My jsp is:
then it has logic:iterate in order to show search result..
And my validator is:
So, what is wrong
I tried to use ValidatorActionForm instead of ValidatorForm... And of course
in my validator call my actionmapping like: "/Colores",
"/Colores?method=buscarColor"... But it doesn't work too...
How can I do???... THanks in advance...
When I turned off validate attribute... It doesn't validate anything... I'm
calling validate method in my action class but it doesn't work...
Qny suggestion???
--
Rafael Taboada
Software Engineer
Cell : +511-97753290
"No creo en el destino pues no me gusta tener la idea de controlar mi vida"
Re: Putting execute() in ActionForm
On 7/11/05, Schaub, Stephen <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > > On the other hand, Stephen, why do you want to have one class per > > page? > > Because I don't want to have to have two classes per page. :) you got me :) I wanted to ask, why would you want to have one *set of classes* for one page, but seems that is not what you want. You just want to combine Action and ActionForm which was my idea too. > Let me clarify that I'm not arguing for one class per page: > in fact, I don't mind having one class backing multiple pages. > Just as Struts allows for one ActionForm that backs multiple JSP's, > my approach allows for one SimpleActionForm that backs multiple > JSP's. I've been working this afternoon on just such a use case. > > What I'm wanting is an explanation of why I should keep the > ActionForm class _separate_ from the Action class. It seems to me > that this unnecessarily complicates the application design. I wanted to combine these two classes as well, but I am not so sure now. Action class is stateless and can serve several requests, whereas action form either is instantiated for every request, or is stateful within a session, and has only one instance per session. Also, Struts is based on idea of subclassing, thus if you already subclassing something like ValidateForm, you cannot subclass another form, which you would want to because it has needed event handlers. So, these differences allow to mix and match and to combine. For example, I have a component which provides CRUD functionality (is it OK that I use my library as an example?). In this case the interface with browser is pretty much stable, it has create(), edit(), view(), delete() and of course render() methods. So, each particular project can reuse not only the protocol, but the implementation too. It is quite standard, it processes button events, it handles error messages, and it returns different mappings for different state of the ActionForm. This Action is totally reusable. On the other hand, every application has its own data which I don't know how to handle. So I have an interface for an action form, which I use from my standard action class. This interface defines what should be done with data for each input event, but it does not define how it should be done. You implement this interface in your ActionForm and go crazy with your data. I don't care what you do, just return back an error message and set status accordingly. What if it were a solid dispatching ActionForm as you suggest? In this case you would not be able to subclass other class like ValidateForm, because multiple inheritance does not exist in Java. At the same time your base ActionForm most likely would not have any functionality, because it depends on actual data. For UI interface, if you decide to add one event, it probably does not really matter, to use a separate action class for that, or to override all form classes... No firm opinion on that. Anyway, I agree that combining Action and ActionForm can be beneficial, but I would not want to *replace* current Struts Action/ActionForm combination with a solid ActionForm. > > Page is not what you load by browser. You load a resource, which > > can potentially generate many different pages. > > I'm not sure I follow. Can you explain further with an example? > I do want to understand. Never mind, I wrote this because I thought that you wanted to "go to login.htm", "then go to homepage.htm" instead of "go to login location, which will display whatever page is proper for current application state". Because if you have stateful objects on the server, and you load a resource, you do not know what exact content you receive. It all depends on server state. But seems that this concept is clear to you, sorry for hitting into the open door ;) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Redirecting to input when validation fails
>From this link, what I understood is that the only real solution is to >manually call the validate method and push the errors in and out of the >session. There is no way to automate it, correct? Thanks, Abdullah -Original Message- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 3:11 PM To: Struts Users Mailing List Subject: Re: Redirecting to input when validation fails On 7/11/05, Abdullah Jibaly <[EMAIL PROTECTED]> wrote: > Hi all, > > I have two action: Display.do and Process.do. > > Display.do forwards to a jsp page. Upon submit, Process.do is invoked. The > action mapping for Process.do specifies Display.do as the input, however, > when form validation for Process.do fails (validate is set to true), the url > still shows Process.do in the browser. Is there a way to make struts do a > redirect to Display.do without losing error messages, etc? http://wiki.apache.org/struts/StrutsCatalogRedirectToInputPage Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graceful way to handle quotation marks in forms
String value1= request.getParameter("value1").replace('\'','`');
Just replace the quotation mark for a backtick. Users will not usually
notice the change :)
--- "Walter, Matt" <[EMAIL PROTECTED]> escribió:
> I was wondering if there was a tried and true method to handle form
> input that had been pasted from Microsoft Word which might contain
> "fancy" quotation marks (U+201C & U+201D aka left and right double
> quotation marks... see
> http://www.fileformat.info/info/unicode/char/201c/index.htm). Currently,
> if we get a form that has them in it, we store the data, and then when
> we display it back to the user, it renders as a question mark in the
> browser.
>
>
>
> Thanks.
>
>
__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: tiles and multipart messages
> I suspect my error is that instead of sending the request directly to > the *Action and then forward - in case of success - to a page > definition, I tried to send the request to a page definition > (containing the *Action) and from the *Action forwarding to a > tile definition. > > Do you agree? Yes. Are you doing some kind of multi-step process where users upload a file, then select some menu option, and then complete the process? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Using struts forms as Value Objects: your opinion?
> W/ a Map:
> - you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
> - It's dynamic, when DAO SQL string changes... so does your
> jxTable/Displaytag.
>
> I removed an entire layer and still have the layer.
>
> Developers are so pasionate... that's what makes them good.
I'm with you on this one. I see DTO's being misused in the Struts
world. The pattern originally solved the overhead associated with
invoking getters/setters over a network. In the world of web browser
sends/requests data from a single application server, where does the DTO
fit in? I don't see it.
That said, a form object is kind of like a DTO in that it serves as a
staging area for the users data and generally has a more fine grained
view of the data (not a 1 to 1 mapping with business domain objects).
Jumping right in, my Actions pass DynaBeans to a service layer. The
service layer processes the DynaBean. Here's an example from a service
interface:
public interface PersonnelService {
/**
* Stores an employee.
*
* id - Long - required for update, null or 0 for create
* first - String
* middle - String (optional)
* last - String
* email - String
* phone - String (optional)
*
* @param employeeBean the bean containing the employee properties
* @return the resultant employee
*/
public Employee storeEmployee(DynaBean employeeBean);
/**
* Gets the employee with the given id.
* @param id id of employee
* @return the employee
*/
public Employee findEmployeeById(long id);
}
Here's an Action that serves as a client for this service:
public class EmployeeAction extends BaseMappingAction {
public ActionForward save(ActionMapping mapping,
ActionForm form, HttpServletRequest
request,
HttpServletResponse response)
throws Exception {
DynaBean employeeBean = (DynaBean) form;
try {
service.storeEmployee(employeeBean);
} catch (...) {
// handle various errors
}
return mapping.findForward("personnel");
}
}
Here's a unit test that serves as a client for this service:
public void testAddEmployee() throws Exception {
DynaBean employeeBean = new LazyDynaBean();
employeeBean.set("first", "Sam");
employeeBean.set("middle", "G");
employeeBean.set("last", "Kroner");
employeeBean.set("email", "[EMAIL PROTECTED]");
employeeBean.set("phone", "(210) 555-7632");
Employee employee = service.storeEmployee(employeeBean);
...
}
Here's an abbreviated implementation of the PersonnelService
storeEmployee method:
public Employee storeEmployee(DynaBean employeeBean) {
Employee employee = new Employee();
// do the work of creating an Employee object based on the bean
...
employeeDAO.store(employee);
return employee;
}
I'm guessing that the coupling police will start screaming... Yes,
there is some documentation overhead in the PersonnelService interface,
but I don't want Actions doing any business logic. Actions simply pass
the data from client, put things in the various scopes, and direct to
the proper view.
The Map camp would probably say that no Employee class is needed at all,
putting me somewhere in between the Map camp and the Bean camp. I use
Hibernate, so beans are the best option on the backend. Apparently
iBatis works very well with maps.
- Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation problem
I usually map multiple actions to the same form. Some have validate = true (for example, doAdd), some have validate = false (for example, viewAdd). Slightly different URL distinguishes them. Does that help? Erik -Original Message- From: Rafael Taboada <[EMAIL PROTECTED]> Sent: Jul 11, 2005 4:49 PM To: Struts List Subject: Validation problem Hi folks, I'm doing my validation for my form fields... I use validation framework, so I don't use validate method in my form bean. The problem I have is the validate is called when I use for first time the module. I mean, when I see for frst ime the HTML form, validation is called... Why??? When I set validate attribute to false in my action mapping, validation is not called... I want the validation is called only when the user click on submit button. Did u have the same problem??? My Action extend DispatchAction class. Thanks in advance. -- Rafael Taboada Software Engineer Cell : +511-97753290 "No creo en el destino pues no me gusta tener la idea de controlar mi vida" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Putting execute() in ActionForm
Michael Jouravlev wrote: > > First of all, to get it over with, Struts Dialogs has plans to combine > Action and ActionForm but it is not there yet :) > > Second, the concept of Struts Dialogs is different. Stephen wants to > have one class -> one page relation. JSF or ASP.NET is the way to go > in this case. My library DOES NOT maintain one-to-one relations of > Java class to a page. Quite contrary, the whole idea is to serve > *different* pages from *one* location. And, if no other hi-tech stuff > like mod-rewrite is used, it means to serve different pages from one > action. This is NOT what Stephen wants. > > On the other hand, Stephen, why do you want to have one class per > page? Because I don't want to have to have two classes per page. :) Let me clarify that I'm not arguing for one class per page: in fact, I don't mind having one class backing multiple pages. Just as Struts allows for one ActionForm that backs multiple JSP's, my approach allows for one SimpleActionForm that backs multiple JSP's. I've been working this afternoon on just such a use case. What I'm wanting is an explanation of why I should keep the ActionForm class _separate_ from the Action class. It seems to me that this unnecessarily complicates the application design. > Page is not what you load by browser. You load a resource, which > can potentially generate many different pages. I'm not sure I follow. Can you explain further with an example? I do want to understand. Thanks for your understanding and thoughtful response, Michael. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation problem
Rafael, turn validation off and call form.validate() manually from your event handler method. Michael. On 7/11/05, Rafael Taboada <[EMAIL PROTECTED]> wrote: > Hi folks, I'm doing my validation for my form fields... > I use validation framework, so I don't use validate method in my form bean. > The problem I have is the validate is called when I use for first time the > module. I mean, when I see for frst ime the HTML form, validation is > called... Why??? > When I set validate attribute to false in my action mapping, validation is > not called... > I want the validation is called only when the user click on submit button. > Did u have the same problem??? > My Action extend DispatchAction class. > Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validation problem
Hi folks, I'm doing my validation for my form fields... I use validation framework, so I don't use validate method in my form bean. The problem I have is the validate is called when I use for first time the module. I mean, when I see for frst ime the HTML form, validation is called... Why??? When I set validate attribute to false in my action mapping, validation is not called... I want the validation is called only when the user click on submit button. Did u have the same problem??? My Action extend DispatchAction class. Thanks in advance. -- Rafael Taboada Software Engineer Cell : +511-97753290 "No creo en el destino pues no me gusta tener la idea de controlar mi vida"
Re: tiles and multipart messages
To be short: >From a tile1.jsp similar to the following: control is passed to the page defined as: SubmitOffer is mapped to the SubmitOfferAction that does the handling of the request. When I do that, the form is always reset before it arrives to the Action. If instead of setting the action to "/MenuSubmitOffer.do", I set it directly to /SubmitOffer.do then everything works fine. I suspect my error is that instead of sending the request directly to the *Action and then forward - in case of success - to a page definition, I tried to send the request to a page definition (containing the *Action) and from the *Action forwarding to a tile definition. Do you agree? TIA Kostas On 7/11/05, Durham David R Jr Ctr 805 CSPTS/SCE < [EMAIL PROTECTED]> wrote: > > > What is the recommended way of working with multipart messages and > > tiles at the same time? > > SFAIK, Tiles and multipart encoding have nothing to do with each other. > You're going to have to post some more info about your problem in order > to get help. > > Try posting the relevant Struts config items, the Action code that > handles uploading, and whatever else you think is related. Maybe > someone will be able to spot the problem(s). > > > - Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: PASSWORD DIGESTION...RealmBase import problem...help please!
Oke Did you read the "How to configure realm" how to doc and follow the instructions ? Take a look at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html Also Its been my experience 8.3 folder are identified coorectly where as NTFS file names sometimes identified correctly e.g. D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\servlet-api.jar become D:\apps\Apache\Tomcat\TOMCAT~1\common\lib\servlet-api.jar Good Luck, Martin - Original Message - From: "O. Oke" <[EMAIL PROTECTED]> To: Sent: Monday, July 11, 2005 3:42 PM Subject: PASSWORD DIGESTION...RealmBase import problem...help please! Help please! BACKGROUND == I want to store the digested version of user's password in the database. Therefore, I imported org.apache.catalina.realm.RealmBase so that I can use the static DIGEST method in the class for the digestion of the password i.e.Digest(myBean.getUser_pass()). I am using Eclipse 3.0.2, tomcat-5.5.9 and JDK 1.5 PROBLEM === After importing org.apache.catalina.realm.RealmBase class, I keep getting error msg: "The import org.apache.catalina cannot be resolved". I do not expect to get this error because I have followed the instructions on how to achieve my objective correctly. The instructions are here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#Digested%20Passwords In line with the instructions, I added catalina.jar to my classpath; please see classpath below: CLASSPATH=.;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\servlet-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\jsp-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\server\lib\catalina.jar In DOS the RealmBase class was found, it is only in the action class that it is not found - cannot be resolved. Everything to do with password/login is working, except for digestion. As I have pointed out it has not been possible to enable digestion because of the problem with importing the class. Can anyone please tell me what I need to do to get round the import problem? I hasten to point out, I even restarted my machine after adding catalina.jar to my classpath. Thank you. Ola'dele Oke ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Graceful way to handle quotation marks in forms
I was wondering if there was a tried and true method to handle form input that had been pasted from Microsoft Word which might contain "fancy" quotation marks (U+201C & U+201D aka left and right double quotation marks... see http://www.fileformat.info/info/unicode/char/201c/index.htm). Currently, if we get a form that has them in it, we store the data, and then when we display it back to the user, it renders as a question mark in the browser. Thanks.
Re: [OT] Re: Unacceptable Behaviour of Mark Galbreath
Dakota Jack wrote: You know what a "canard" is Newton? Front control surface on an airplane? Really, these questions are too easy. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Displaying data from a form bean
There is no such tag, however, in your action do:
request.setAttribute("myformbean", form)
and your jsp below will work...
Abdullah
-Original Message-
From: Schaub, Stephen [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 3:08 PM
To: Struts Users Mailing List (E-mail)
Subject: Displaying data from a form bean
Newbie question:
Struts lets me bind ActionForm properties to HTML form components like this:
Enter customer name:
...
I don't have to name the form bean, because Struts will look it up in the
struts-config file for me.
I'm trying to get Struts to output the contents of an ActionForm property,
without binding it to an input control. Currently, I'm using to render
the display-only info. However, this requires me to name the form bean
explicitly, which I would like to avoid:
Enter customer name:
...
I looked through the struts tags looking for one that simply emits the
data in the specified form bean, but I can't find one. What am I missing?
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirecting to input when validation fails
On 7/11/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Michael, don't worry we like your stuff:) You don't have to create posts > from fake email addresses and names like Abdullah Jibaly and Stephen Schaub. Rick, I hope you are kidding (is it Friday already?), because these posts are real. At least, they are not sent by me ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: Call me stupid but I don't even know what p-langs are (languages I can urinate on?:) lol. PHP (Friendster tried J2EE, went to PHP). Part of LAMP stack, conisdered most effective. Try Tiki-Wiki or Drupal when you get a project, you are 80% done. Python (used by Google) Plone (use on Spring home page) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Ok, yes they'd have to extend that in order to utilize your processing > in the ActionForm functionality. Bottom line is I think all you've done > is move where you do the processing... you moved it from the Actions to > the ActionForms. If you like this approach definitely check out > StrutsDialog. (Sorry Michael, not trying to oversimplify all that your > stuff does, I realize it's much more than processing in the ActionForm, > but if he's going to do this he might as well stand on the shoulders of > someone who has done all the work already:) On 7/11/05, Schaub, Stephen <[EMAIL PROTECTED]> wrote: > I took a brief look, but I don't see how StrutsDialogs corresponds to what > I'm suggesting. It appears to maintain a separation of Action and ActionForm, > which I am proposing to combine. First of all, to get it over with, Struts Dialogs has plans to combine Action and ActionForm but it is not there yet :) Second, the concept of Struts Dialogs is different. Stephen wants to have one class -> one page relation. JSF or ASP.NET is the way to go in this case. My library DOES NOT maintain one-to-one relations of Java class to a page. Quite contrary, the whole idea is to serve *different* pages from *one* location. And, if no other hi-tech stuff like mod-rewrite is used, it means to serve different pages from one action. This is NOT what Stephen wants. On the other hand, Stephen, why do you want to have one class per page? Page is not what you load by browser. You load a resource, which can potentially generate many different pages. This is much more flexible. Even MS is adding Front Controller to ASP.NET 2.0, realising limitations of Page Controller architecture, which it uses in current ASP.NET 1.1 Think again, why exactly you want to address to a *page* istead of addressing to a *resource*. P.S. As Craig M. explained, one of the reasons of having one-to-one class->page relationship in JSF is the simplicity of this concept to [current and former] desktop app developers. But it does not necessarily mean that this concept is better, than Front Controller used in Struts. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 4:20 PM: Realy Rick, please try Groovy... it's the answer that's looking for you. I am sure you have read some of the Rails press. Actually, Groovy is one of the things I do want to take a look at. Hopefully one of these days I'll get to it:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirecting to input when validation fails
Michael Jouravlev wrote the following on 7/11/2005 4:11 PM: On 7/11/05, Abdullah Jibaly <[EMAIL PROTECTED]> wrote: Hi all, I have two action: Display.do and Process.do. Display.do forwards to a jsp page. Upon submit, Process.do is invoked. The action mapping for Process.do specifies Display.do as the input, however, when form validation for Process.do fails (validate is set to true), the url still shows Process.do in the browser. Is there a way to make struts do a redirect to Display.do without losing error messages, etc? http://wiki.apache.org/struts/StrutsCatalogRedirectToInputPage Michael, don't worry we like your stuff:) You don't have to create posts from fake email addresses and names like Abdullah Jibaly and Stephen Schaub. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote:
They have to look at a database model in order to figure
out how to get back a dateOfBirth field?
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days.
Now
they want to iterate over this list and display some properties.
I use JXTable that needs a tableModel.
I wrote a class that extends tableModel that takes init(List)
In Struts, you can pass the List to DisplayTag, but you know that.
they'll have to look up the database model.
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days. Did you bring that
up again?
I'm just glad I don't have to
work on projects where I have to go to the datamodel to figure out the
names of my properties to use as a key in order to get out a property
from a Map.
what if you had...
if ( someCondition ) {
Integer age = (Integer)employee.get("DOB");
//other stuff
}
We almost never see class cast exception in practice.
> How does the developer know what "type"
was used for the value? I can look at a bean and see...
No type. Look, lots of developers are using dynamic langs.
I suggest you try Groovy one time, just play w/ it. Its
Better/Faster/Ligher J2EE.
Realy Rick, please try Groovy... it's the answer that's looking for you.
I am sure you have read some of the Rails press.
Double price; but I have not idea what type of value
shippingOrder.get("price") is. The developer just has to guess or where
does he look? The datamodel?
OK... I see your main point is that one has to memorize the data model.
In order to write good fast scalaeable querries you have to know the
model.
DBA is resposible for the data model. They tend to be VERY experienced
w/ production issues. So I leverage their experience over java
developers, most Java people tend to have less than 10 years prof. exp.
> Sure
if only one person has to deal with the code, it 'might' be faster since
he might simply remember all the types etc, but what happens when the
code is inherited? Pity on that developer.
Good theory that I used to beleive.
In practice, that is why I went from Beans to Maps. 10% of get/sets on a
project tend to be deprecated either becuase of model changes or becuase
of view changes.
W/ a Map:
- you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
- It's dynamic, when DAO SQL string changes... so does your
jxTable/Displaytag.
I removed an entire layer and still have the layer.
Developers are so pasionate... that's what makes them good.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
Schaub, Stephen wrote the following on 7/11/2005 3:56 PM: Yes -- it is supposed to be abstract -- each ActionForm subclass must define an execute() method to perform the processing for that form. (Right but in your example you were showing LoginAction as the implementing class and you still kept it abstract in the example- probaby just cut and paste errror no big deal) If you like this approach definitely check out StrutsDialog. Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine. Actually you might want to get with Michael, he has been talking about combining the ActionForm and Action together, and I too think that's the best approach to take if you plan to push the business logic into the ActionForm. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
On 7/11/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Schaub, Stephen wrote the following on 7/11/2005 2:07 PM: > > > With this approach, most JSP pages could have a single Java class -- > > a SimpleActionForm subclass that handles both validation and > > processing for the page: > > Michael, is this guy a plant from your StrutsDialog camp?:) I wanted to post something like "Rick, Ted and other orthodox guys, check out this guy's suggestion", but then I decided not to ;-) Michael. Oh, almost forgot the plug: Struts Dialogs, http://struts.sourceforge.net/strutsdialogs/index.html ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I can't initialize de Serlvet Action :(
Mariano- Can you show us the StackTrace from display or your logs??? Buena Suerte, Martin- - Original Message - From: "Zarar Siddiqi" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Monday, July 11, 2005 2:32 PM Subject: Re: I can't initialize de Serlvet Action :( The trouble is that you're not saying much. - Original Message - From: "Mariano Petrakovsky" <[EMAIL PROTECTED]> To: "Lista de correo de Struts" Sent: Monday, July 11, 2005 2:26 PM Subject: I can't initialize de Serlvet Action :( Throw an exception ServletAction can't load... In my .jsp say me same (I'm using eclipe)... what should be the troubble? -- Mariano G. Petrakovsky Programmer · Software Factory AXG Tecnonexo - www.tecnonexo.com Development facilities:Av. Maipú 1252 8º (C1006ACT) · Buenos Aires · Argentina. Tel.: (54-11) 4878-0005 - Fax: (54-11) 4878-0065. Headquarters: 1604 Spring Hill Road, Suite 160 Vienna · VA 22182 · USA. Tel.: (202) 986-7541 - Fax: (202) 787-3891. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirecting to input when validation fails
On 7/11/05, Abdullah Jibaly <[EMAIL PROTECTED]> wrote: > Hi all, > > I have two action: Display.do and Process.do. > > Display.do forwards to a jsp page. Upon submit, Process.do is invoked. The > action mapping for Process.do specifies Display.do as the input, however, > when form validation for Process.do fails (validate is set to true), the url > still shows Process.do in the browser. Is there a way to make struts do a > redirect to Display.do without losing error messages, etc? http://wiki.apache.org/struts/StrutsCatalogRedirectToInputPage Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Putting execute() in ActionForm
Zarar Siddiqi wrote: > I think the ideal that you're searching for is "one class per > view". Take a look at JSF. That's correct. And I'm familiar with JSF -- but it's way too complicated for my needs. Plus Struts is dictated for this project... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vignette V6 Struts-based web application
For that specific capability I would contact Vignette directly at [EMAIL PROTECTED] Good Luck, - Original Message - From: "Rick Reumann" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Monday, July 11, 2005 3:14 PM Subject: Re: Vignette V6 Struts-based web application Kareem Hassan wrote the following on 7/7/2005 5:59 AM: I am new to Vignette CMS and was wandering that if someone could help me out how a Struts-based web application can fit into Vignette CM model ? I'm working on a Strut-based project and am told that I have to let Vignette JSP controller to handle all JSPs rendering/forwarding and throw away existing Struts framework, which uses its own action controller to handle all JSP presentation. Is this true? Any workarounds? or Can Vignette just manage Struts actions url pattern /do/MyAction instead of /pages/MyPage.jsp? Vingnette - run away, run far away:) In all seriousness, though, some people have worked with vingnette stuff before here and it has been nothing but headaches. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
I think the ideal that you're searching for is "one class per view". Take a look at JSF. - Original Message - From: "Schaub, Stephen" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Monday, July 11, 2005 3:56 PM Subject: RE: Putting execute() in ActionForm Rick Reumann wrote: > With this approach, most JSP pages could have a single Java class -- > a SimpleActionForm subclass that handles both validation and > processing for the page: Well they certainly wouldn't have a 'single' java class, you would have a LOT of them. Sorry -- I meant a single Java class per JSP page, instead of _two_ Java classes (an Action and an ActionForm) per JSP page. I don't think you meant for that to be abstract. But notice you know have an execute in all your ActionForms? How is that different than simply the processing done in different Actions as Struts is now? All you've done is pushed down the processing to a different place.. ActionForm vs Action. Yes -- it is supposed to be abstract -- each ActionForm subclass must define an execute() method to perform the processing for that form. You're right in saying that All I've done is push the processing to a different place -- but it's for the purpose of combining the Action and the ActionForm to reduce the number of separate Java classes needed for a typical Struts app, hopefully reducing complexity. If you like this approach definitely check out StrutsDialog. Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Displaying data from a form bean
Newbie question: Struts lets me bind ActionForm properties to HTML form components like this: Enter customer name: ... I don't have to name the form bean, because Struts will look it up in the struts-config file for me. I'm trying to get Struts to output the contents of an ActionForm property, without binding it to an input control. Currently, I'm using to render the display-only info. However, this requires me to name the form bean explicitly, which I would like to avoid: Enter customer name: ... I looked through the struts tags looking for one that simply emits the data in the specified form bean, but I can't find one. What am I missing? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FRIDAY] Re: Using struts forms as Value Objects: your opinion?
Frank W. Zammetti wrote the following on 7/11/2005 4:00 PM: Ditto :) (That's my Patrick Swayze moment for the day) awhhh shucks, I thought you were a Rush Ditto-head for a moment:) See I labeled this thread [FRIDAY] - I didn't want the sruts-list users police showing up (just messin around guys, point taken on cutting down on OT posts..yada.. yada.. yada:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> A bean is self-documenting in that you can immediately tell what its
> attributes are and what types they are. I'm not even talking about
> generating javadoc from the source either, but that's certainly a very
> nice by-product.
If I could have a property in Delphi or C# style... Or if I could at
least write something like that:
/**
* Flag that demo mode is on
*/
private boolean isDemo;
public boolean getIsDemo() { ... }
public setIsDemo(boolean isDemo) { ... }
... and my methods *would be commented in javadoc* too, it would be
much better than current approach with lots of lines and comments for
each getter/setter. Three properties commented in current approved
Java style, and you already lost in the code. This sucks.
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 3:36 PM: Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. Vic, I love you man, but coming back with what Flash or some other XML/kitchenSink/FlavorOfTheMonth/SOAP/MOMMA/EJB/hibernate-ibatis/JAX/DNC/GOP/ACLU/EPA/DEA language does isn't germane to the situation. Call me stupid but I don't even know what p-langs are (languages I can urinate on?:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: But also remember it's not just about how nice it is to find out the types and names of the properties. Using Maps can introduce a lot of hidden bugs that are difficult to track down (mentioned just a few in last e-mail) Ditto :) (That's my Patrick Swayze moment for the day) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Putting execute() in ActionForm
Rick Reumann wrote: > > With this approach, most JSP pages could have a single Java class -- > > a SimpleActionForm subclass that handles both validation and > > processing for the page: > > Well they certainly wouldn't have a 'single' java class, you > would have > a LOT of them. Sorry -- I meant a single Java class per JSP page, instead of _two_ Java classes (an Action and an ActionForm) per JSP page. > I don't think you meant for that to be abstract. But notice you know > have an execute in all your ActionForms? How is that different than > simply the processing done in different Actions as Struts is now? All > you've done is pushed down the processing to a different place.. > ActionForm vs Action. Yes -- it is supposed to be abstract -- each ActionForm subclass must define an execute() method to perform the processing for that form. You're right in saying that All I've done is push the processing to a different place -- but it's for the purpose of combining the Action and the ActionForm to reduce the number of separate Java classes needed for a typical Struts app, hopefully reducing complexity. > If you like this approach definitely check out StrutsDialog. Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
-1 for maps after how strongly typed is an object???
+1 for Value Objects If you follow the axiom from Floyd Marinescu
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
serverDesign custom value objects that wrap arbitrary sets of data as needed
by the client, completely decoupled from the layout of the domain model on
the serverDesign custom value objects that wrap arbitrary sets of data as
needed by the client, completely decoupled from the layout of the domain
model on the serverDesign custom value objects that wrap arbitrary sets of
data as needed by the client
completely decouple from the layout of the domain model of the server
excerpted from this analysis of ValueObjects,VO Factory available from the
birthplace of HAL at University of Illinois Urbana
http://72.14.207.104/search?q=cache:AgD8-5ccZJ4J:jerry.cs.uiuc.edu/~plop/plop2001/accepted_submissions/PLoP2001/fmarinescu0/PLoP2001_fmarinescu0_0.pdf+%22ValueObject%22+AND+%22Map%22&hl=en
HTH,
Martin-
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
server- Original Message -
From: "Rick Reumann" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List"
Sent: Monday, July 11, 2005 2:56 PM
Subject: Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 2:15 PM:
I think it vastly simplifies to use Maps in places where I used to use
beans. (I even got rid of baseBeans domain how much I loved maps)
Vic I think you sleep with the Map API under your pillow at night or use
it as a Teddy Bear when you sleep:)
I agree Maps will work fine for rapid development, but I like the type
safety of using typed properties in my VOs.
Just as an example, I know we both use iBATIS, under your Map idea, you
could end up with the crap out occuring at the DB level whereas if you use
a typed POJO you'll find the error much sooner. What if in your scenario
you pass in some mangled up String represntation of a Date as your value
in your map and the backend then needs to process that as Date in the DB?
You'll end up with a DB exception. Using normally typed POJOs you won't
have this problem since you'll catch it much sooner when trying to do the
conversion of your String to Date.
The other aspect is just the pure functionality of using a typed VO vs a
Map. For example if you are using a Map to represent an Employee how do
you know what to name the keys? Someone can put in map.put("firstName",
name ).. someone else might put map.put("fName", name ) ? even using
Constants is messy (map.put(Constants.NAME, name).. granted that's better
but now you have to maintain a constants class as well as you Map in place
of a standard POJO?
How do you deal with these issues? How does a developer working on your
code know how to even get the properties out of your Map? I guess he has
to look at some API contract saying put date of birth in the Map as "dob"
not "dateOfBirth." Also, the rapid development using Maps will sure end
up being a drawback when you end up having to work with the Maps. In my
IDE I can get dot completion to work easily but that's not gonig to work
with your Map approach. If I need firstName from employee I can just do
employee(dot)=[pop up of methods]... you're going to get .. employee.
[ get, put, etc Map methods !]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Frank W. Zammetti wrote the following on 7/11/2005 3:48 PM: A bean is self-documenting in that you can immediately tell what its attributes are and what types they are. I'm not even talking about generating javadoc from the source either, but that's certainly a very nice by-product. amen:) But also remember it's not just about how nice it is to find out the types and names of the properties. Using Maps can introduce a lot of hidden bugs that are difficult to track down (mentioned just a few in last e-mail) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 3:25 PM:
Rick Reumann wrote:
How does a developer working on your
code know how to even get the properties out of your Map? I guess he
has to look at some API contract saying put date of birth in the Map
as "dob" not "dateOfBirth."
As in iBatis, name of the map property is in my case the field name in
the table, and I do not have to map it, it compes that way.
But my point is users using your API, how do they know what they are
getting back? They have to look at a database model in order to figure
out how to get back a dateOfBirth field? That's crazy imo. Someone is
coding and they call List employees = mapHappyVic.getEmpoyees(); Now
they want to iterate over this list and display some properties. Tell me
how they figure out what the fields are to pull from the Map? Using
regular POJOS and an IDE or even the java docs (for the vi users:)
they'll be able to figure out what to call, for your List of Maps of
employees they'll have to look up the database model.
Some people don't get dynamic langs yet... just like some people took a
long time to get OO. It's much less code.
Come on! what kind of comparison is that - comparing the use of Maps to
coming around to understanding OO? Anyway, use your Maps, I'm not saying
they are a poor choice in all cases, but I think it's an unwise decision
in most cases for model layer objects. I'm just glad I don't have to
work on projects where I have to go to the datamodel to figure out the
names of my properties to use as a key in order to get out a property
from a Map. Not only that, you have no type safety plus think of all the
stupid time wasted debugging because using that approach you'll no
compile time checks. I can type employee.getDOB() if it's
employee.getDateOfBirth, but you certainly won't have a compilation
problem with employee.get("DOB") Also, think of the potential for bugs
to not creep up until odd times... what if you had...
if ( someCondition ) {
Integer age = (Integer)employee.get("DOB");
//other stuff
}
if DOB should be dateOfBirth you might not even find about the error
until "somceCondition" is met. On top of that, look at the other
situation, math operations How does the developer know what "type"
was used for the value? I can look at a bean and see...
Double price; but I have not idea what type of value
shippingOrder.get("price") is. The developer just has to guess or where
does he look? The datamodel? Some other docs? Pain in the butt if you
ask me. I swear using Maps will cost a lot of time in the long run. Sure
if only one person has to deal with the code, it 'might' be faster since
he might simply remember all the types etc, but what happens when the
code is inherited? Pity on that developer.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
It's ironic to me that I had this same discussion with someone at work just last week :) I *was* in the "Maps are better" camp until a few months back when I changed my mind, and it comes down to one thing: Self-documenting code is better. A bean is self-documenting in that you can immediately tell what its attributes are and what types they are. I'm not even talking about generating javadoc from the source either, but that's certainly a very nice by-product. Developers HATE documenting. I'm sure there are exceptions, but by and large that is a very fair generalization in my experience. If you trust a developer to document what is going into a Map, your asking for trouble, generally-speaking. I don't personally use an IDE, but I think Rick's point about auto-completion and the like is important because many people *DO* use IDEs, and if you give them a bean they can be more effective faster than if you give them a map with some documentation on what they may find in it at various points in time, and that's even assuming the documentation is accurate :) Especially in a team environment, I would always go with a real bean now over a Map-based design, even though I agree with may of the points made on why Maps are good. But in this world of trade-offs, I think you gain more by using a bean than you do by using a Map, again, generally-speaking. Frank netsql wrote: Larry Meadors wrote: Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry Get/Set, Get/Set Half the time I have no idea what the db date will come back as. Look, I think some of you will belive me that I know well the benefits of beans and that I have done at least several deployed projects w/ beans. It was a best aproach for the time. Now I have an alternative. It does not change jUnit testing in anyway, I fire a populate/CRUDs and assert. So using maps does not make me insane. :-P Compile time type checking? Like in dynamic langs? Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. So I just duplicate their aproach to get their Cost of Operation. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PASSWORD DIGESTION...RealmBase import problem...help please!
Help please! BACKGROUND == I want to store the digested version of user's password in the database. Therefore, I imported org.apache.catalina.realm.RealmBase so that I can use the static DIGEST method in the class for the digestion of the password i.e.Digest(myBean.getUser_pass()). I am using Eclipse 3.0.2, tomcat-5.5.9 and JDK 1.5 PROBLEM === After importing org.apache.catalina.realm.RealmBase class, I keep getting error msg: "The import org.apache.catalina cannot be resolved". I do not expect to get this error because I have followed the instructions on how to achieve my objective correctly. The instructions are here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#Digested%20Passwords In line with the instructions, I added catalina.jar to my classpath; please see classpath below: CLASSPATH=.;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\servlet-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\jsp-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\server\lib\catalina.jar In DOS the RealmBase class was found, it is only in the action class that it is not found - cannot be resolved. Everything to do with password/login is working, except for digestion. As I have pointed out it has not been possible to enable digestion because of the problem with importing the class. Can anyone please tell me what I need to do to get round the import problem? I hasten to point out, I even restarted my machine after adding catalina.jar to my classpath. Thank you. Ola'dele Oke ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Larry Meadors wrote: Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry Get/Set, Get/Set Half the time I have no idea what the db date will come back as. Look, I think some of you will belive me that I know well the benefits of beans and that I have done at least several deployed projects w/ beans. It was a best aproach for the time. Now I have an alternative. It does not change jUnit testing in anyway, I fire a populate/CRUDs and assert. So using maps does not make me insane. :-P Compile time type checking? Like in dynamic langs? Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. So I just duplicate their aproach to get their Cost of Operation. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:
public class SimpleAction extends Action { public ActionForward
execute( ActionMapping mapping, ActionForm form, HttpServletRequest
request, HttpServletResponse response) throws Exception {
SimpleActionForm bean = (SimpleActionForm)form; return
bean.execute(mapping, request, response); } }
You can do that, although I still like my business logic done higher up
in the Action (Servlet) that I submit to rather than having it be done
in the Object that is backing the view (your ActionForm subclass).
Michael Jouravlev on this list does this and his stuff looks very nice
if you want to take this approach.
With this approach, most JSP pages could have a single Java class --
a SimpleActionForm subclass that handles both validation and
processing for the page:
Well they certainly wouldn't have a 'single' java class, you would have
a LOT of them. I can have one ActionForm (if I wanted) for my entire
application but you will definitely have many of them to process the
business logic. You mean you'll have 'one' java class that is extended.
I don't see the big deal of that since Struts has the same concept..
your ActionForms extend a flavor of the ActionForm base class.
public class LoginForm extends SimpleActionForm { private String
username; private String password; ... getter and setter methods ...
public abstract ActionForward execute( ActionMapping mapping,
HttpServletRequest request, HttpServletResponse response) throws
Exception { ... Login processing ... } public ActionErrors
validate(ActionMapping mapping, HttpServletRequest req) { ...
validation code ... }
}
I don't think you meant for that to be abstract. But notice you know
have an execute in all your ActionForms? How is that different than
simply the processing done in different Actions as Struts is now? All
you've done is pushed down the processing to a different place..
ActionForm vs Action.
Then, in my struts-config.xml file, most form beans would extend the
SimpleActionForm, and most actions would use the SimpleAction type:
Ok, yes they'd have to extend that in order to utilize your processing
in the ActionForm functionality. Bottom line is I think all you've done
is move where you do the processing... you moved it from the Actions to
the ActionForms. If you like this approach definitely check out
StrutsDialog. (Sorry Michael, not trying to oversimplify all that your
stuff does, I realize it's much more than processing in the ActionForm,
but if he's going to do this he might as well stand on the shoulders of
someone who has done all the work already:)
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Redirecting to input when validation fails
Hi all, I have two action: Display.do and Process.do. Display.do forwards to a jsp page. Upon submit, Process.do is invoked. The action mapping for Process.do specifies Display.do as the input, however, when form validation for Process.do fails (validate is set to true), the url still shows Process.do in the browser. Is there a way to make struts do a redirect to Display.do without losing error messages, etc? Thanks, Abdullah - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: How does a developer working on your code know how to even get the properties out of your Map? I guess he has to look at some API contract saying put date of birth in the Map as "dob" not "dateOfBirth." As in iBatis, name of the map property is in my case the field name in the table, and I do not have to map it, it compes that way. Think how rarely you get class cast exceptions! Very rare. Forget you CS 101. > In my IDE I can get dot completion to work easily but that's not gonig to work with your Map approach. If I need firstName from employee I can just do employee(dot)=[pop up of methods]... you're going to get .. employee. [ get, put, etc Map methods !] I have been using Flash, CoR and Groovy and got used to the dynamic nature and maps (CoR Context is a map too, I use it as a sort of a vararg). Also, w/ XML. Imagine a XML used for SoA you knid of have to know what you are getting so you can show a jTable. I just have a XML DAO (ibatis) and a model that only has a populate/crud methods, no gets/sets. On a large project, the fact that there are thousands of classes not in a project is a huge maitanace improvment. Anytime my developer would think bean use a map instead. See post by Jeff Butler on "Map over Bean" in iBatis list. Before that multiple developers develop a similar "CutomerBean" and as the front end or back end would change, they had CRUFT geters/setters. (on 1up.com project) With a Map... there are 0 such clases. Some people don't get dynamic langs yet... just like some people took a long time to get OO. It's much less code. You can use validator w/ map, DynaMaps... It's diferent. Anywho... that what my team does on this JDNC project. .V ps/ot: Did you say IDE dot completion? ;-) I don't need no stinking badges. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry On 7/11/05, netsql <[EMAIL PROTECTED]> wrote: > of course... I use Collections (Maps and Lists) as VO/DTO. > You can wrap them w/ DynaMaps, you can validate a map, you don't have to > maintain deprecated gets/sets, it reduces duplication... your dao > can return a map/collection/list... > > I think it vastly simplifies to use Maps in places where I used to use > beans. (I even got rid of baseBeans domain how much I loved maps) > > .V > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting execute() in ActionForm
Schaub, Stephen wrote the following on 7/11/2005 2:07 PM: With this approach, most JSP pages could have a single Java class -- a SimpleActionForm subclass that handles both validation and processing for the page: Michael, is this guy a plant from your StrutsDialog camp?:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vignette V6 Struts-based web application
Kareem Hassan wrote the following on 7/7/2005 5:59 AM: I am new to Vignette CMS and was wandering that if someone could help me out how a Struts-based web application can fit into Vignette CM model ? I'm working on a Strut-based project and am told that I have to let Vignette JSP controller to handle all JSPs rendering/forwarding and throw away existing Struts framework, which uses its own action controller to handle all JSP presentation. Is this true? Any workarounds? or Can Vignette just manage Struts actions url pattern /do/MyAction instead of /pages/MyPage.jsp? Vingnette - run away, run far away:) In all seriousness, though, some people have worked with vingnette stuff before here and it has been nothing but headaches. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 2:15 PM:
I think it vastly simplifies to use Maps in places where I used to use
beans. (I even got rid of baseBeans domain how much I loved maps)
Vic I think you sleep with the Map API under your pillow at night or use
it as a Teddy Bear when you sleep:)
I agree Maps will work fine for rapid development, but I like the type
safety of using typed properties in my VOs.
Just as an example, I know we both use iBATIS, under your Map idea, you
could end up with the crap out occuring at the DB level whereas if you
use a typed POJO you'll find the error much sooner. What if in your
scenario you pass in some mangled up String represntation of a Date as
your value in your map and the backend then needs to process that as
Date in the DB? You'll end up with a DB exception. Using normally typed
POJOs you won't have this problem since you'll catch it much sooner when
trying to do the conversion of your String to Date.
The other aspect is just the pure functionality of using a typed VO vs a
Map. For example if you are using a Map to represent an Employee how do
you know what to name the keys? Someone can put in map.put("firstName",
name ).. someone else might put map.put("fName", name ) ? even using
Constants is messy (map.put(Constants.NAME, name).. granted that's
better but now you have to maintain a constants class as well as you Map
in place of a standard POJO?
How do you deal with these issues? How does a developer working on your
code know how to even get the properties out of your Map? I guess he has
to look at some API contract saying put date of birth in the Map as
"dob" not "dateOfBirth." Also, the rapid development using Maps will
sure end up being a drawback when you end up having to work with the
Maps. In my IDE I can get dot completion to work easily but that's not
gonig to work with your Map approach. If I need firstName from employee
I can just do employee(dot)=[pop up of methods]... you're going to get
.. employee. [ get, put, etc Map methods !]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
On 7/11/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > When I've had to do something like this in the past, I didn't > actually change the target, but rather caused the response page to > use the new target as part of its page loading. That is, the > response page would have an onload handler which would load the > necessary content in a new target. This looks easier than to call validate() from already opened popup. I like this one. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
David Johnson wrote the following on 7/11/2005 2:23 PM:
Joe
Oh this one sounds good. I'm not sure how I'd actually DO that though.. can
you provide more info? All my pages are tiles definitions right now. How
would I cause the response page to use the new target (conditionally)?
what about something like... one JSP page for form.
//bottom of JSP .. although probably will work fine up top
document.forms[0].target=newTarget;
document.forms[0].dispatch.value="pdfProcess";
document.forms[0].submit();
Your dispatch Action:
validateMe(...) {
form.validate()...
//if ok ...
request.setAttribute("openPDF",true);
//else if failed...save errors
request.setAttribute("openPDF",false);
//forward to same JSP
}
pdfProcess(..) {
//normal proces of form data to create your PDF or whatever
//forward page to display PDF
}
Key is to call validate manually in your action.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I can't initialize de Serlvet Action :(
The trouble is that you're not saying much. - Original Message - From: "Mariano Petrakovsky" <[EMAIL PROTECTED]> To: "Lista de correo de Struts" Sent: Monday, July 11, 2005 2:26 PM Subject: I can't initialize de Serlvet Action :( Throw an exception ServletAction can't load... In my .jsp say me same (I'm using eclipe)... what should be the troubble? -- Mariano G. Petrakovsky Programmer · Software Factory AXG Tecnonexo - www.tecnonexo.com Development facilities:Av. Maipú 1252 8º (C1006ACT) · Buenos Aires · Argentina. Tel.: (54-11) 4878-0005 - Fax: (54-11) 4878-0065. Headquarters: 1604 Spring Hill Road, Suite 160 Vienna · VA 22182 · USA. Tel.: (202) 986-7541 - Fax: (202) 787-3891. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PASSWORD DIGESTION...RealmBase import problem...help please!
Help please! BACKGROUND == I want to store the digested version of user's password in the database. Therefore, I imported org.apache.catalina.realm.RealmBase so that I can use the static DIGEST method in the class for the digestion of the password i.e.Digest(myBean.getUser_pass()). I am using Eclipse 3.0.2, tomcat-5.5.9 and JDK 1.5 PROBLEM === After importing org.apache.catalina.realm.RealmBase class, I keep getting error msg: "The import org.apache.catalina cannot be resolved". I do not expect to get this error because I have followed the instructions on how to achieve my objective correctly. The instructions are here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#Digested%20Passwords In line with the instructions, I added catalina.jar to my classpath; please see classpath below: CLASSPATH=.;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\servlet-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\common\lib\jsp-api.jar;D:\apps\Apache\Tomcat\tomcat-5.5.9\server\lib\catalina.jar In DOS the RealmBase class was found, it is only in the action class that it is not found - cannot be resolved. Everything to do with password/login is working, except for digestion. As I have pointed out it has not been possible to enable digestion because of the problem with importing the class. Can anyone please tell me what I need to do to get round the import problem? I hasten to point out, I even restarted my machine after adding catalina.jar to my classpath. Thank you. Ola'dele Oke ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I can't initialize de Serlvet Action :(
Throw an exception ServletAction can't load... In my .jsp say me same (I'm using eclipe)... what should be the troubble? -- Mariano G. Petrakovsky Programmer · Software Factory AXG Tecnonexo - www.tecnonexo.com Development facilities:Av. Maipú 1252 8º (C1006ACT) · Buenos Aires · Argentina. Tel.: (54-11) 4878-0005 - Fax: (54-11) 4878-0065. Headquarters: 1604 Spring Hill Road, Suite 160 Vienna · VA 22182 · USA. Tel.: (202) 986-7541 - Fax: (202) 787-3891. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
Joe
Oh this one sounds good. I'm not sure how I'd actually DO that though.. can
you provide more info? All my pages are tiles definitions right now. How
would I cause the response page to use the new target (conditionally)?
On 7/11/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> When I've had to do something like this in the past, I didn't
> actually change the target, but rather caused the response page to
> use the new target as part of its page loading. That is, the
> response page would have an onload handler which would load the
> necessary content in a new target.
>
> If your new target is a new window, pop-up blockers may foil this,
> and of course, you'll have to make sure to preserve any relevant
> state, since the onload handler will initiate a separate request.
>
> Can you make that work?
>
> Joe
>
>
> At 1:49 PM -0400 7/11/05, David Johnson wrote:
> >Hi all
> > I have the following problem:
> > I have a button on my form that uses javascript to change to form target
> >before submitting because I'm exporting an RTF generated in my action to
> the
> >new browser, as follows
> >
> > >onclick="set('export');setFormTarget('_export')"
> >disabled="false">Create Graph (Popup)
> >
> >function setFormTarget(newTarget){
> >document.forms[0].target=newTarget;
> >}
> >
> >The thing is I want to be able to use the validate() method in my Form
> >object and return to the ORIGINAL browser if an error is encountered...
> >
> >so is there anything I can do within the action to affect that?
> >
> >Thanks
> >
> >--
> >-Dave
> >[EMAIL PROTECTED]
>
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
-Dave
[EMAIL PROTECTED]
Re: Changing Form Target in Action?
Hmm.
I suppose it would be easier to just do the validation in JavaScript... but
I **really** dont want to. It just seems inconsistent.
So there's no way to change what browser the validate() returns to once
I've submitted the form and I'm in the validate() method? Some attribute on
the request perhaps? I mean the request has to know where it's forwarding
to, right?
On 7/11/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> When I've had to do something like this in the past, I didn't
> actually change the target, but rather caused the response page to
> use the new target as part of its page loading. That is, the
> response page would have an onload handler which would load the
> necessary content in a new target.
>
> If your new target is a new window, pop-up blockers may foil this,
> and of course, you'll have to make sure to preserve any relevant
> state, since the onload handler will initiate a separate request.
>
> Can you make that work?
>
> Joe
>
>
> At 1:49 PM -0400 7/11/05, David Johnson wrote:
> >Hi all
> > I have the following problem:
> > I have a button on my form that uses javascript to change to form target
> >before submitting because I'm exporting an RTF generated in my action to
> the
> >new browser, as follows
> >
> > >onclick="set('export');setFormTarget('_export')"
> >disabled="false">Create Graph (Popup)
> >
> >function setFormTarget(newTarget){
> >document.forms[0].target=newTarget;
> >}
> >
> >The thing is I want to be able to use the validate() method in my Form
> >object and return to the ORIGINAL browser if an error is encountered...
> >
> >so is there anything I can do within the action to affect that?
> >
> >Thanks
> >
> >--
> >-Dave
> >[EMAIL PROTECTED]
>
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
-Dave
[EMAIL PROTECTED]
Re: Changing Form Target in Action?
Hi David,
If I'm understanding your goal correctly, then you won't be able to do
this without some sort of scripting because the form target is a purely
client-side attribute, you won't be able to change it from the
server-side, which is really what you'd want to do.
If scripting is OK with you, there are some approaches...
(1) Use Ajax... submit the form and render the response. When you get
it back, examine it... if it's an error response (you'll have to figure
out how to determine this based on what your app does), then your still
on the page and can do whatever you like (i.e., show errors, whatever).
If it's not an error response, open a popup at that point, or perhaps
just display what was sent back in a , what is appropriate.
(2) Along the lines of 1, use frames... target your form to a hidden
frame (set rows or cols, depending on the layour, to 0). When the
response comes back, include in it some simple Javascript that either
opens the popup and copies the HTML over to it, or display error
responses, in response to onLoad.
(3) As Michael suggested, target the new window as your doing now, and
simply return some Javascript that either closes the popup, and probably
pass the error information back to the parent before that, or continue
as usual. This happens in response to the onLoad event of course.
#1 is probably the approach that gives the best UI experience, but #3 is
probably the simplest to implement. All require scripting though. If
you decide to go with #1, the AjaxTags component of my Java Web Parts
project may save you a lot of time
(http://javawebparts.sourceforge.net). If you go with either of the
other suggestions, feel free to ping me if you have specific questions
about them.
Frank
Michael Jouravlev wrote:
On 7/11/05, David Johnson <[EMAIL PROTECTED]> wrote:
Hi all
I have the following problem:
I have a button on my form that uses javascript to change to form target
before submitting because I'm exporting an RTF generated in my action to the
new browser, as follows
Create Graph (Popup)
function setFormTarget(newTarget){
document.forms[0].target=newTarget;
}
The thing is I want to be able to use the validate() method in my Form
object and return to the ORIGINAL browser if an error is encountered...
so is there anything I can do within the action to affect that?
Thanks
I never done stuff with popup windows, but I would consider trying
something like this:
* you open a new window and submit to action which validates input
(automatic validation is turned off);
* you manually call validate() from action class, and if input is
incorrect, you return a small html with javascript, which would close
current window (which is a popup), and would redirect to main window.
The downside: would not work without javascript. The location of main
window should be set either in struts-config.xml or maybe passed as
parameter or maybe found out via referer... Also, to show errors after
redirect you would have to stick them into session beforehand. Or to
append to redirected request.
* if data is ok, you respond with pdf to popup window directly or
forward/redirect
to action which responds with pdf.
As a side note, I personally don't like apps which open windows
themselves. I prefer to use "Open in a new window" option if I need it
in a new window.
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
of course... I use Collections (Maps and Lists) as VO/DTO. You can wrap them w/ DynaMaps, you can validate a map, you don't have to maintain deprecated gets/sets, it reduces duplication... your dao can return a map/collection/list... I think it vastly simplifies to use Maps in places where I used to use beans. (I even got rid of baseBeans domain how much I loved maps) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
When I've had to do something like this in the past, I didn't
actually change the target, but rather caused the response page to
use the new target as part of its page loading. That is, the
response page would have an onload handler which would load the
necessary content in a new target.
If your new target is a new window, pop-up blockers may foil this,
and of course, you'll have to make sure to preserve any relevant
state, since the onload handler will initiate a separate request.
Can you make that work?
Joe
At 1:49 PM -0400 7/11/05, David Johnson wrote:
Hi all
I have the following problem:
I have a button on my form that uses javascript to change to form target
before submitting because I'm exporting an RTF generated in my action to the
new browser, as follows
Create Graph (Popup)
function setFormTarget(newTarget){
document.forms[0].target=newTarget;
}
The thing is I want to be able to use the validate() method in my Form
object and return to the ORIGINAL browser if an error is encountered...
so is there anything I can do within the action to affect that?
Thanks
--
-Dave
[EMAIL PROTECTED]
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: tiles definition versus global forward issue
Got it.
Forward must be replaced by an action:
Instead of global forward:
-Original Message-
From: Faber, Szczepan [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 4:13 PM
To: Struts Users Mailing List
Subject: RE: tiles definition versus global forward issue
Correction:
def.createItineraries is configured in tiles-defs.xml:
Struts-config.xml:
-Original Message-
From: Faber, Szczepan [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 4:08 PM
To: Struts Users Mailing List
Subject: tiles definition versus global forward issue
Hello
Struts 1.2.7 - tile definition use problem.
I cannot use tile definition within the global forward (output is http
404):
Rule tester
def.createItineraries is configured in tiles-defs.xml:
and works properly if I use it from Action class:
return mapping.findForward("index")
Did anyone have similar problems?
Thanks for any help.
Szczepan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Putting execute() in ActionForm
I'm interested in some feedback on the following:
I prefer to develop web applications using a page-centric model. I like the
simplicity of one JSP <-> one Java class for the view layer (not the model).
Struts, with its separate Action and ActionForm classes, tends toward at least
two Java classes for a JSP: an Action, and an ActionForm. This tends toward a
multiplicity of Java classes. (I know it's possible to share a single
ActionForm and Action for multiple JSP's, but I'm looking for a simpler
approach.)
I would like to create a generic Action class that delegates request processing
to a SimpleActionForm, like this:
public abstract class SimpleActionForm extends ActionForm {
public abstract ActionForward execute(
ActionMapping mapping,
HttpServletRequest request,
HttpServletResponse response) throws Exception;
}
public class SimpleAction extends Action {
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
SimpleActionForm bean = (SimpleActionForm)form;
return bean.execute(mapping, request, response);
}
}
With this approach, most JSP pages could have a single Java class -- a
SimpleActionForm subclass that handles both validation and processing for the
page:
public class LoginForm extends SimpleActionForm {
private String username;
private String password;
... getter and setter methods ...
public abstract ActionForward execute(
ActionMapping mapping,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
... Login processing ...
}
public ActionErrors validate(ActionMapping mapping, HttpServletRequest
req) {
... validation code ...
}
}
Then, in my struts-config.xml file, most form beans would extend the
SimpleActionForm, and most actions would use the SimpleAction type:
...
I don't have a lot of experience with Struts, so I'm interested on feedback
about this approach. Is it a good/bad idea? If bad, why?
Thanks in advance,
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
On 7/11/05, David Johnson <[EMAIL PROTECTED]> wrote:
> Hi all
> I have the following problem:
> I have a button on my form that uses javascript to change to form target
> before submitting because I'm exporting an RTF generated in my action to the
> new browser, as follows
>
> onclick="set('export');setFormTarget('_export')"
> disabled="false">Create Graph (Popup)
>
> function setFormTarget(newTarget){
> document.forms[0].target=newTarget;
> }
>
> The thing is I want to be able to use the validate() method in my Form
> object and return to the ORIGINAL browser if an error is encountered...
>
> so is there anything I can do within the action to affect that?
>
> Thanks
I never done stuff with popup windows, but I would consider trying
something like this:
* you open a new window and submit to action which validates input
(automatic validation is turned off);
* you manually call validate() from action class, and if input is
incorrect, you return a small html with javascript, which would close
current window (which is a popup), and would redirect to main window.
The downside: would not work without javascript. The location of main
window should be set either in struts-config.xml or maybe passed as
parameter or maybe found out via referer... Also, to show errors after
redirect you would have to stick them into session beforehand. Or to
append to redirected request.
* if data is ok, you respond with pdf to popup window directly or
forward/redirect
to action which responds with pdf.
As a side note, I personally don't like apps which open windows
themselves. I prefer to use "Open in a new window" option if I need it
in a new window.
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Form Target in Action?
David Johnson wrote the following on 7/11/2005 1:49 PM: The thing is I want to be able to use the validate() method in my Form object and return to the ORIGINAL browser if an error is encountered... Hmmm, not sure about this, this sounds tricky but I bet someone more knowledgeable knows the answer. I think most of the work will have to have to be on the client side. In other words, at a first stab at this, on the resulting page you'll need a test for the errors present and if so, then force a reload of the other window you came from and close this new window that you spawned. In order to make sure the errors you want show up on the original page when it refreshes you'll have to probably store the errors initially in the Session so that the other page will see them or pass the error message(s) in the url/action that you call from the new window which is used to refresh the old. Haven't done this myself, so I could be wrong or there may be an easier way. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing Form Target in Action?
Hi all
I have the following problem:
I have a button on my form that uses javascript to change to form target
before submitting because I'm exporting an RTF generated in my action to the
new browser, as follows
Create Graph (Popup)
function setFormTarget(newTarget){
document.forms[0].target=newTarget;
}
The thing is I want to be able to use the validate() method in my Form
object and return to the ORIGINAL browser if an error is encountered...
so is there anything I can do within the action to affect that?
Thanks
--
-Dave
[EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Borislav Sabev wrote the following on 7/11/2005 1:37 PM: In case of the Integer there is pre-load default value and EVEN if conversion fails during the population phase, it just use is the dafault value (and you think it's parsed correctly). In the previous example its a coincidence that Rivka have 0 as default value (it's just the same value as init value of IntegerConverter). Bingo:) Sorry saw this thread late and could have helped out much sooner. This is a HUGE problem with BeanUtils and why I end up having to register custom converters:( BeanUtils (at least it always has done this, maybe in a recent version it's hopefully changed?), will end up converting null values to 0!! Stupid, stupid if you ask me (null means null not 0!) Goes the same for the other numeric wrappers as well. (I think their argument was for backwards compatibility with apps that expect that behavior). In regard to you point... The strange point is that I didn't find how can I set a default date value ... if someone knows it, please share this knowledge here. You shouldn't want a "default" at all provided by BeanUtils for cases where it can be null! You are using the anomoly of the way Integer is working and wanting to propogate that poor solution. null should be null.. it shouldn't be 0 or some default Date if null is provided. If you want a default Date or some other default than provide that before going to your form...or if after it submits and you see a null, then provide the default. You could of course register your own converter to provide a default for when a Date is null- but I would NOT do this. Actually, in regards to a Date, in case you didn't already realize, you'll have to provide your own converter anyway if you plan to use java.util.Date since BeanUtils doesn't provide that by default.. it only provides conversion for java.sql.Date. If you need help with the converters I can post some code or search the struts archives for "java.util.Date converter" -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload/download file to/from oracle blob field with struts
I had to do this for an application. While the code is fairly lengthy, longer than I'd like to post here, if you come up against specific problems feel free to ping me. Although I didn't look at the article Martin referenced for you, it's a fairly generic problem, not something that you will write a bunch of Oracle-specific code for (I suppose you *could*, but at least when I did it I did not, and it was straight JDBC coding). Frank EROL TEZCAN wrote: Hi, I want to upload/download a file to/from oracle blob field. How can I do this ? Please give an example code. Thanks, Erol __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Nitish Kumar wrote:
I think raghavendra is right.
Rivka, your code is working because you are using primitive type int and not
the wrapper type Integer.
In case of primitive type in case of any exception, it gives you a default
value.
Thanks and Regards,
Nitish Kumar
So after small debugging session I found why it works for Integers and
not for dates (at least in my case)
all classes that implment Convertors interface in BeanUtils, have
something like this as implementation of convert() method:
public Object convert(Class type, Object value) {
if (value == null) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException("No value specified");
}
}
if (value instanceof Date) {
return (value);
}
try {
return (Date.valueOf(value.toString()));
} catch (Exception e) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException(e);
}
}
}
In case of the Integer there is pre-load default value and EVEN if
conversion fails during the population phase, it just use is the dafault
value (and you think it's parsed correctly). In the previous example its
a coincidence that Rivka have 0 as default value (it's just the same
value as init value of IntegerConverter).
The strange point is that I didn't find how can I set a default date
value ... if someone knows it, please share this knowledge here.
For sure this is not a big discovery, but I spent a lot of hours to
udnerstand it and I though that this should be described somewhere at
some public place ... that's why I was a bit bitter in my previuos posts
Regards
Borislav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] UML class diagrams
ArgoUML will do it. On 7/11/05, David Whipple <[EMAIL PROTECTED]> wrote: > Anyone have any suggestions for an opensource/freeware tool for reverse > engineering java code to class diagrams? > > Thanks, > Dave > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > JSF still differentiates "real" object (whatever it might be, a real > business object or a VO) from visual component data, which I don't > like. From my point of view, it is much easier to have an object with > an ID, to view/edit it, or to delete it. Therefore, I do not need > viewstate for UI components. I only need to store my object somewhere > like in session while I work with it. I want my widgets and my view to > be as dumb as possible. All data and state that I need is in real > objects, I do not need artificial viewstate to duplicate it. Before anyone corrects me, I want to say that I went a little overboard ;) There are selection lists, treeviews and other objects which do not have direct representation in the domain model. These objects should be maintained by web framework. I was talking primarily about input/output panels and about item lists. Well, item list may be also considered as pure view object, consisting of business objects... Whatever. In this case I was talking about input/output panels only ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] UML class diagrams
Anyone have any suggestions for an opensource/freeware tool for reverse engineering java code to class diagrams? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
There's probably something to that, Leon. Of course, there's nothing new here, except maybe the metaphor. Using the layers pattern in enteprise applications is well known. I believe Bushman describes it in POSA. Here's another online treatment: * http://www.stevenblack.com/PTN-Layers.asp -Ted. On 7/11/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > Some time ago I tried to postulate an enterprise application as a > row of mvc patterns each using the previous one as the model, and everyone > laughed at me :-) > > Now this is the same, with a nicer metaphor :-) > > Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Personally I prefer to keep form beans and value objects seperate, for two > key reasons: > > 1) form beans generally should consist of String data to facilitate > round-tripping of invalid inputs. I like to constrain them to a clearly > defined role of marshaling data 'into' and 'out of' the presentation layer, > i.e. across the boundary between presentation and application. Is not it easier to have one nested VO/BO with string properties, than to copy properties back and forth from action form to VO? I use web framework only to expose my real objects to the outer world. > 2) value objects should use typed interfaces to ensure marshaling to and > from presentation format (string types) is pushed as far up the application > stack as possible. This also enables other, potentially type-aware, > presentation / client tiers to be built on top of the same value objects > (e.g. for a web-services interface). I think I do not agree with this one. Let's take it as a design requirement that application that we build is a webapp. It potentially can have different interfaces. This would mean, that: * input data is stingified because of HTTP * Struts is not the only front end Therefore, it is much easier to create BO/VO with dual string/typed interface or with string interface only. It would do validation and conversion to native datatype internally instead of doing it in validate() method. I believen that this is more flexible approach. What are you going to do with your validation code, if you are told to move from Struts to WebWork or Tapestry? On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Form beans are part of the *view* tier, not the model ... their > purpose in life is to represent the server side state of the HTML > elements on a form, even if that state is invalid (i.e. not currently > passing all the validations). That way, you can reproduce what the > user typed so he or she can fix it, rather than presenting them with a > completely blank screen. (This is why you generally use string fields > in a form bean). This is one way to look at things. Another way is to use VO/BO for input/output directly. When I use existing data, I load it into BO and display it. When I modify it, I update BO using its string properties. If I decide to cancel updates, I siply remove the BO from memory, no database changes needed. If I create a new object, I create a new BO and fill it in. Until I persist it, it hangs in the session. If I decide to cancel, then I remove it, and database would not even know that I was about to insert an object. > In a component oriented framework like JSF or Tapestry, you don't need > to worry about keeping track of this state information ... the > components do it for you. JSF still differentiates "real" object (whatever it might be, a real business object or a VO) from visual component data, which I don't like. From my point of view, it is much easier to have an object with an ID, to view/edit it, or to delete it. Therefore, I do not need viewstate for UI components. I only need to store my object somewhere like in session while I work with it. I want my widgets and my view to be as dumb as possible. All data and state that I need is in real objects, I do not need artificial viewstate to duplicate it. I can understand why JSF or ASP.NET went this route with UI objects and viewstate: to abstract from the model/business layer. They do not want to establish a firm contract with business/persistence layer. They do not want to require a certain BO lifecycle or the datatype limitations. But I as a developer find this inconvenient. Web frameworks designers focus on their framework, while I as an application designer, focus on business data, business process and business state. Take ActiveX. There is a contract, there are interfaces, methods and datatypes defined. Just build an object according to the protocol, and you will be able to have design-time interface, runtime interface, everything. Web frameworks do not want to have strict contracts with data layer probabaly to be more flexible. I would take contract over flexibily anytime. Presuming that this is a flexible contract ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
