Re: 1.x - DTD Attribute Proposal
On 6/23/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I find two uses of action mappings in my applications. One loads data for view, another writes data and then goes to a view. These views, I suppose, would logically be "pages" if Struts were a page-based controller. But I do find this kind of use-case always cropping into my apps, and one of my biggest problems is that when I do a save or cancel, I have no automated stack that tells me what my last logical view was. So I'd like to propose allowing developers to mark actions as a page or a view (and I have not finialized my nomenclature, so please help me word it better). Then Struts can keep a running stack, at some N depth (maybe just 1), that would allow me to always return to the previous view. In the Action class: Action.findPreviousPageForward(); Thoughts, O comrades? Paul, first about "view" attribute. I bunnied up it first ;-) It is mine :-)) Now about going to a previous view. I guess that in attempt to break from stateless page-oriented paradigm of many Struts apps I might have gotten into confines of object-oriented paradigm. So please correct me if I will be wrong here. To me, Action or Action/ActionForm combination represents a logical web resource, or a business object if you will. It is usually a stateful object: even if I don't use session, I might save its state in the database. So to me, navigating to Action means "Hey, object, show yourself in the way that corresponds to your current state". This is particularly true when pages are fronted with Action classes. When I navigate to a web resource I don't really know what will be shown. I think that Craig had this idea in mind when he explained why ActionForward should represent a logical outcome of an Action, not a menu choice [1]. So, to me going to "previous view" does not make a lot of sense. What if the object that is rendered by this view has changed its state or has gone out of scope? Umm... From another point of view, you want to mark a whole mapping as "view", this is different than marking a particular page. So, you mean that some of your actions/resources can render themselves and some cannot, and you want to keep count only of these that can? In this case my argument above does not make much sense but I will keep it anyway ;-) On the other hand, if it is an interactive application, a user must always be presented with something to look at, right? So if response is not immediately followed by a redirected request, it represents a view. These views can be accounted for without modifying action mapping. I think I miss something here :-) Maybe you want to say, that an action can have different query parameters and thus one action will be considered as different resources. While browser differentiates resources by full URL including parameters, you want to differentiate just by base URL, right? I guess this makes sense... Michael. [1] http://wiki.apache.org/struts/ActionForward - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.x - DTD Attribute Proposal
On 6/27/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/23/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > I find two uses of action mappings in my applications. One loads data for view, another writes data and then goes to a view. These views, I suppose, would logically be "pages" if Struts were a page-based controller. But I do find this kind of use-case always cropping into my apps, and one of my biggest problems is that when I do a save or cancel, I have no automated stack that tells me what my last logical view was. > > So I'd like to propose allowing developers to mark actions as a page or a view (and I have not finialized my nomenclature, so please help me word it better). Then Struts can keep a running stack, at some N depth (maybe just 1), that would allow me to always return to the previous view. > > > > In the Action class: > Action.findPreviousPageForward(); > > Thoughts, O comrades? Paul, first about "view" attribute. I bunnied up it first ;-) It is mine :-)) Now about going to a previous view. I guess that in attempt to break from stateless page-oriented paradigm of many Struts apps I might have gotten into confines of object-oriented paradigm. So please correct me if I will be wrong here. To me, Action or Action/ActionForm combination represents a logical web resource, or a business object if you will. It is usually a stateful object: even if I don't use session, I might save its state in the database. So to me, navigating to Action means "Hey, object, show yourself in the way that corresponds to your current state". This is particularly true when pages are fronted with Action classes. When I navigate to a web resource I don't really know what will be shown. I think that Craig had this idea in mind when he explained why ActionForward should represent a logical outcome of an Action, not a menu choice [1]. So, to me going to "previous view" does not make a lot of sense. What if the object that is rendered by this view has changed its state or has gone out of scope? Umm... From another point of view, you want to mark a whole mapping as "view", this is different than marking a particular page. So, you mean that some of your actions/resources can render themselves and some cannot, and you want to keep count only of these that can? In this case my argument above does not make much sense but I will keep it anyway ;-) On the other hand, if it is an interactive application, a user must always be presented with something to look at, right? So if response is not immediately followed by a redirected request, it represents a view. These views can be accounted for without modifying action mapping. I think I miss something here :-) Maybe you want to say, that an action can have different query parameters and thus one action will be considered as different resources. While browser differentiates resources by full URL including parameters, you want to differentiate just by base URL, right? I guess this makes sense... Michael. [1] http://wiki.apache.org/struts/ActionForward Ok, I think I got it :) Say, you have a.do with page="true" Then you call b.do with no page attribute, this action does not return a view and forwards directly to c.do Then you fool around c.do, producing c.do?param1, c.do?param2, c.do?param3 Then you want to cancel your c.do action as if it were a dialog window. You want to return to a.do. You cannot simply use last URL, because it would be c.do?param2 since browser treats URL as different if they have different params. Am I right? Whenever you call an action, controller would verify if it is a "current" action. If yes, it won't add it to the "unwind list". Same with actions that do not produce views. I think this makes sense. It will be useful. Of course, if you open a new window after, say, c.do?param3 and the go to a previous action, you will get a.do in your second window. Is this a bug? I guess not. After all, if a user opens a new window he knows what to expect ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Patrick Lightbody WebWork Presentation / BayCHI / 15 May 2006
Hi All Announcement message from the JAVAWUG I am pleased to announce that Patrick Lightbody's presentation for BayCHI Silicon Valley Bay Area JUG is NOW available from GoogleVideo. http://video.google.com/videoplay?docid=6908607645517853283 Thanks to Mike Van-Riper, and also to Dave Evans, Wendy Smoak, Vik Cekvenich, and Don Brown Stay tuned. Enjoy! -- Peter Pilgrim ( Windows XP / Thunderbird 1.5 ) _ ___ + Expert Java __ /_ ___ ___ ____ /__ / + Enterprise ___ _ /_ __ `/_ | / / __ `/__ __/ __ __/ + Design / /_/ / / /_/ /__ |/ // /_/ / _ /___ _ /___ + Architecture \/ \__,_/ _/ \__,_/ /_/ /_/ + Web New Age On Line Resume || \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Friday] GWT/Struts - does it make sense?
Martin - I think we are saying the same thing - and I think you confirm this in your last paragraph. Rather than web frameworks, using GWT I think developers are more likely to integrate directly with XWork (as a generic command infrastructure, rather than a web front controller), Spring or the business logic directly. This avoids adding abstraction layers to the design/architecture that don't contribute anything useful in the way of functionality. /Ian Martin Cooper wrote: On 6/23/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I have been thinking about this a lot lately, and I would say that GWT is more likely to replace web frameworks than work with them. I wouldn't phrase it quite like that. It's more like AJAX in general changes the way in which we build the server side of web apps, and GWT demonstrates that more dramatically than many people have seen before. If you really buy into the AJAX way of building web apps (i.e. not just adding tweaky bits to existing apps), then the most dramatic change is that you find yourself writing very little server side code. (I'm not talking about the "business logic" here, only what sits on top of it.) Once you have something in place that deserialises requests and serialises responses (which GWT provides with their RemoteServiceServlet), then almost all you have left to do is implement CRUD operations on top of the business logic. At my last company (meaning up until a week ago), perhaps only 10% of the code we wrote for our newest app is server side Java code. I did put Struts 1.3 in place early on, but we ended up with exactly two action mappings for the entire app. (We have two only because we're using two different client-side technologies; one mapping would be the norm.) As for using Struts with GWT, I'm not sure that I see the point. You could, yes, but why would you? You'd either have to provide your own code to do all of what their RemoteServiceServlet does, or you'd have to futz with the client side code so that it doesn't use it, and basically reinvent the way in which RemoteServiceServlet works anyway. On the surface, that might not seem so hard, but if Google has done its job properly, there's a lot more to it that there might appear. -- Martin Cooper /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Michael Jouravlev wrote: >> From another thread: > > On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> JSF is a major shift in the way we've been doing things. >> It will take a while for everyone to understand JSF enough >> before they are ready for Shale. > > I think that it should not be too complex to combine GWT front end > with Struts backend. I haven't tried it yet but does it really matter, > pure servlet or Struts Action, it is just a URL after all. GWT is new > and fun, yet it might allow to reuse existing skills if not code. > Struts would be used for server-side validation, model/database > access/update, state management. > > Looking into Ajax future I think that from both developer and user > perspective GWT/Struts can be a sensible option for rich web > applications in comparison with JSF/Shale/ICEFaces/whatnot. Opinions? > > I know, I know, "It is up to you to make it happen" ;-) > > - > 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]
OGNL - Getter and setter types must match
I've run into this problem with OGNL where I want it to invoke a setter, but if there's a getter method with the same property name but a different type, OGNL will just fail silently. Why does it even care about the getter? Anyone have an idea of what's going on here? I'm working against the OGNL version that went out w/ WW 2.2.2. Bob
Re: [Friday] GWT/Struts - does it make sense?
On 6/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/23/06, Ian Roughley <[EMAIL PROTECTED]> wrote: > > I have been thinking about this a lot lately, and I would say that GWT > is more likely to replace web frameworks than work with them. I wouldn't phrase it quite like that. It's more like AJAX in general changes the way in which we build the server side of web apps, and GWT demonstrates that more dramatically than many people have seen before. If you really buy into the AJAX way of building web apps (i.e. not just adding tweaky bits to existing apps), then the most dramatic change is that you find yourself writing very little server side code. (I'm not talking about the "business logic" here, only what sits on top of it.) Once you have something in place that deserialises requests and serialises responses (which GWT provides with their RemoteServiceServlet), then almost all you have left to do is implement CRUD operations on top of the business logic. It is kinda like when Tucker appeared (Citroen DS for those on the other side of the pond) that all other cars of that time immediately became obsolete. Still usable, but obsolete nevertheless. The funniest thing is that Tucker and DS are still pretty amazing even now, despite that other guys had half a century to catch on. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: I've run into this problem with OGNL where I want it to invoke a setter, but if there's a getter method with the same property name but a different type, OGNL will just fail silently. Why does it even care about the getter? Anyone have an idea of what's going on here? I'm working against the OGNL version that went out w/ WW 2.2.2. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
On 6/27/06, Bob Lee <[EMAIL PROTECTED]> wrote: I've run into this problem with OGNL where I want it to invoke a setter, but if there's a getter method with the same property name but a different type, OGNL will just fail silently. Why does it even care about the getter? Anyone have an idea of what's going on here? I'm working against the OGNL version that went out w/ WW 2.2.2. This may be way off, but it sounds like you're running into the naming conventions in the JavaBeans specification. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
Thanks for the explanation. What a silly restriction. Anybody up for removing it? I don't have access to the OGNL source. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: > I've run into this problem with OGNL where I want it to invoke a > setter, but > if there's a getter method with the same property name but a different > type, > OGNL will just fail silently. Why does it even care about the getter? > Anyone > have an idea of what's going on here? > > I'm working against the OGNL version that went out w/ WW 2.2.2. > > Bob > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
I'd be up for lifting the restriction, but I also don't have access to the code. /Ian Bob Lee wrote: Thanks for the explanation. What a silly restriction. Anybody up for removing it? I don't have access to the OGNL source. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: > I've run into this problem with OGNL where I want it to invoke a > setter, but > if there's a getter method with the same property name but a different > type, > OGNL will just fail silently. Why does it even care about the getter? > Anyone > have an idea of what's going on here? > > I'm working against the OGNL version that went out w/ WW 2.2.2. > > Bob > - 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: [Friday] GWT/Struts - does it make sense?
You can use GWT standalone, but it also makes sense to use it for rich components embedded in a normal web page. For example, you could use it to implement an AJAX table component which can sort columns and page-by-page iterate. As for using XWork on the server side, I personally wouldn't do it because I like type checking and dislike XML. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote: Martin - I think we are saying the same thing - and I think you confirm this in your last paragraph. Rather than web frameworks, using GWT I think developers are more likely to integrate directly with XWork (as a generic command infrastructure, rather than a web front controller), Spring or the business logic directly. This avoids adding abstraction layers to the design/architecture that don't contribute anything useful in the way of functionality. /Ian Martin Cooper wrote: > On 6/23/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >> >> I have been thinking about this a lot lately, and I would say that GWT >> is more likely to replace web frameworks than work with them. > > > I wouldn't phrase it quite like that. It's more like AJAX in general > changes > the way in which we build the server side of web apps, and GWT > demonstrates > that more dramatically than many people have seen before. > > If you really buy into the AJAX way of building web apps (i.e. not just > adding tweaky bits to existing apps), then the most dramatic change is > that > you find yourself writing very little server side code. (I'm not talking > about the "business logic" here, only what sits on top of it.) Once > you have > something in place that deserialises requests and serialises responses > (which GWT provides with their RemoteServiceServlet), then almost all you > have left to do is implement CRUD operations on top of the business > logic. > > At my last company (meaning up until a week ago), perhaps only 10% of the > code we wrote for our newest app is server side Java code. I did put > Struts > 1.3 in place early on, but we ended up with exactly two action > mappings for > the entire app. (We have two only because we're using two different > client-side technologies; one mapping would be the norm.) > > As for using Struts with GWT, I'm not sure that I see the point. You > could, > yes, but why would you? You'd either have to provide your own code to > do all > of what their RemoteServiceServlet does, or you'd have to futz with the > client side code so that it doesn't use it, and basically reinvent the > way > in which RemoteServiceServlet works anyway. On the surface, that might > not > seem so hard, but if Google has done its job properly, there's a lot > more to > it that there might appear. > > -- > Martin Cooper > > > /Ian >> >> -- >> From Down & Around, Inc. >> Innovative IT Solutions >> Software Architecture * Design * Development >> ~ >> web: www.fdar.com >> email [EMAIL PROTECTED] >> phone:617.821.5430 >> ~ >> >> >> >> Michael Jouravlev wrote: >> >> From another thread: >> > >> > On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> >> JSF is a major shift in the way we've been doing things. >> >> It will take a while for everyone to understand JSF enough >> >> before they are ready for Shale. >> > >> > I think that it should not be too complex to combine GWT front end >> > with Struts backend. I haven't tried it yet but does it really matter, >> > pure servlet or Struts Action, it is just a URL after all. GWT is new >> > and fun, yet it might allow to reuse existing skills if not code. >> > Struts would be used for server-side validation, model/database >> > access/update, state management. >> > >> > Looking into Ajax future I think that from both developer and user >> > perspective GWT/Struts can be a sensible option for rich web >> > applications in comparison with JSF/Shale/ICEFaces/whatnot. Opinions? >> > >> > I know, I know, "It is up to you to make it happen" ;-) >> > >> > - >> > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
It has to do with the java.beans.Introspector. It doesn't find the properties correctly if the getter and setter don't match. It won't be able to figure out what the property type is if they aren't the same for the same name. I don't remember what the heuristic is, but if you think about it, it will either find a property based on the getter or the setter, with their respective types, but the property will only have one method, the getter or the setter, but not both. Each have their own problems and would keep bean binding with OGNL from working. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=35707&messageID=69900#69900 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
I did think about it, and it's not logical. Why do I want to lump getters and setters together to fit some artificial notion of a "property?" The answer is I don't. I don't think there's a justification for doing so that matters to users, and there are plenty of reason for a getter and setter to respectively return and accept different types. OGNL using Introspector and Introspector exhibiting this behavior is not a good reason. Even if we did enforce this behavior purposefully, failing silently is evil. Bob On 6/27/06, Jason Carreira <[EMAIL PROTECTED]> wrote: It has to do with the java.beans.Introspector. It doesn't find the properties correctly if the getter and setter don't match. It won't be able to figure out what the property type is if they aren't the same for the same name. I don't remember what the heuristic is, but if you think about it, it will either find a property based on the getter or the setter, with their respective types, but the property will only have one method, the getter or the setter, but not both. Each have their own problems and would keep bean binding with OGNL from working. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=35707&messageID=69900#69900 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
On 6/27/06, Jason Carreira <[EMAIL PROTECTED]> wrote: It has to do with the java.beans.Introspector. It doesn't find the properties correctly if the getter and setter don't match. It won't be able to figure out what the property type is if they aren't the same for the same name. It's in Section 8.3: http://java.sun.com/products/javabeans/docs/spec.html -- Wendy ... who wonders if Bob can free us from the tyranny of the JavaBeans spec, under which we have labored for so long... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
> I did think about it, and it's not logical. Why do I > want to lump getters > and setters together to fit some artificial notion of > a "property?" The > answer is I don't. I don't think there's a > justification for doing so that > matters to users, and there are plenty of reason for > a getter and setter to > respectively return and accept different types. OGNL > using Introspector and > Introspector exhibiting this behavior is not a good > reason. > Well, unless we want to rewrite OGNL to not use the native reflection capabilities of JavaBeans, and write our own based on name patterns only, I think we're stuck with it. It's really not that bad. Rename either the getter or the setter. > Even if we did enforce this behavior purposefully, > failing silently is evil. > Well, yes... But if you have the dev mode on, it will log errors for web parameters that don't match bean properties. > > Bob > - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=35707&messageID=69908#69908 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
