Re: double submit problem
On 1/6/06, Rafael Taboada <[EMAIL PROTECTED]> wrote: > Hi folks... I'm trying to solve my problem when an user submit a form and he > clicks the submit button more than twice. > > My app runs perfect... I mean, It saves data. But in this case, it saves > data as many clicks the user does. > > Do u know how I can solve that? > > I'm trying to use Struts Dialog: > http://struts.sourceforge.net/strutsdialogs/dialogaction.html > > I implemented an app using that but it still has the same problem... why? > maybe I'm doing something wrong??? I followed the login sample. But in my > case I have a NewData module. Struts Dialogs does not help to avoid *explicit* resubmits when you go back and hit submit button again. It helps to fight *implicit* resubmits when a user hits "Refresh" button to refload a page. The Login Dialog sample is built in a way that you cannot hit Back button and get to login form, because Login Dialog is stateful and renders non-cachable content. Therefore after you log in and click Back, you will see Logout page, not Login page. Even if you use browser like Opera and you was able to submit the same content again, it is up to the data model to recognise this and either to allow it or to forbid it. Struts Dialogs assumes that web resources are stateful and render themselves according to their state. It does not contain any means like tokens to prevent double submit if your data model and rendering approach allows so. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The framework I think I want...
On 1/7/06, Daniel Blumenthal <[EMAIL PROTECTED]> wrote: > I noticed that I haven't used any > ActionForms (yet). Everything is being communicated via AJAX, and I just > haven't needed any. ActionForms and Ajax are not related. By the way, may I assume that your app does not work with Javascript turned off or in Gen4 browsers? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
I am developping a navigation panel like the panel2 from tomahawk (I
had to offer some more features) and I like the way you can embedd
some navigation items tags (NavigationItem, NavigationItems) inside
the navigation tag to specify the different elements of the panel.
Since the navigation model elements need some more attributes then
SelectItem like an action attribute (supporting MethodBinding of
course), you end up developping some custom models elements just
adding some more attributes. I think this part is alright, I don't
want to use something generic like DynaFormBean in Struts but I think
some base model elements could be standardized like a base class Item
and some subclasses like SelectItem and ActionItem (I read somewhere
there something similar in Oracle ADF components, maybe I should take
a look).
The problem I see here is you have to implement for each kind of
model, two custom UIxxxItem and UIxxxItems components so you can end
up with a lot of redundant UI components. This problem is quite
familiar in the OO world and it is usually solved elegantly by the
Bridge pattern, where here model elements are the abstraction
hierarchy and the UIxxxItem and UIxxxItems are the implementations
specific. So what I would like is to be able to always use the same UI
components to specify the model of a parent UI component. What I am
doing right now, is whenever a component have a model defined by child
elements, it implements a custom interface having a method returning
the model class it supports and making sure all model elements have a
constructor taking a properties map as an input (in case the element
must be built from the UIxxxItem properties). Then I have developped a
custom iterator capable of going throught any UI component model
implemented by those standard model UI components. Maybe someone have
a better design to propose me but it seems to do the trick for the
moment. What do you think?
Of course with JSP you need to developp a lot of custom tags but I
guess not with Clay or facelets :))
Here's the link to the Tomahawk panel I was refering to :
http://www.irian.at/myfaces/panelnavigation_2.jsp.source
On 1/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Just a couple of comments intermixed below.
>
> On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
> >
> > Ok can we all ignore the troll and go back to the original subject...
> >
> > Like Craig pointed out Rick, I think you should play around with JSF
> > first and then Shale.
> > The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> > think one of the previous poster posted the link.
> >
> > Shale is decomposed in modules so it not so hard to get a grab on the
> > functionalities, one type at a time. Actually, it's not very complex
> > except maybe the Clay plugin wich does require some time to understand
> > but using it or Facelets instead of JSP is worth the troubles in my
> > opinion.
> >
> > Anyway, I have been playing with JSF for sometimes now and here's the
> > various differences against Struts I've found :
> >
> > - ActionForm and Action (more Dispatch Action in fact) are replaced by
> > backing beans.
> > No more copy between ActionForm and Domain objets or data transfer
> > objects are necessary.
> >
> > -The event model is fine-grained instead of coarse-grained. In struts,
> > you don't have a true event model and the only event is receive a
> > request and the *listeners* Action, are application wide.
> >
> > In JSF, the basic event listener are registered on a single component
> > instead of the complete application. You have two basic different
> > events (ActionEvent and ValueChangeEvent) and the event listeners all
> > receive an event object representing the event context.
>
>
> While these are the only two events defined in the standard, it is perfectly
> feasible for JSF components to define their own events, and their own event
> handlers, using the same basic infrastructure.
>
> Plus, in JSF
> > you can register more then one listeners on a component so no need for
> > Action chaining and the troubles coming along with it. Note that the
> > action events listeners are not responsible to choose the next view
> > like the actions are in Struts. It's quite a change but you get used
> > to it very fast in the end and this way your backing beans (most of
> > the time, they are the action listeners) are easier to reuse. Overall,
> > you can understand this quite fast if you are use to program Swing
> > applications.
>
>
> I actually wish there wasn't be so much difference here :-(. In the
> original vision of Struts, the idea of an ActionForward was very much to
> describe an *outcome* ("this is what happened"), not a *destination* ("this
> is where to go next"). Unfortunately, most Struts developers don't use
> forwards that way -- and you can make exactly the same "mistake" :-) when
> using logical outcomes in JSF.
>
> - The binding mechanism is way more powerful then Struts one and I
> > th
Re: Noob Q: "Failed to obtain specified collection"
Josh McDonald wrote:
Quick question - what's this _actually_ mean? It's obviously found the
field, because if I change the reference in the JSP to something wrong,
it gives me a different error ("No getter found" or something similar).
Makes no real sense to me. Where should I look for my mistakes? I've
added bean references at the top of the JSP, they seem OK and don't
trigger any errors.
Is the get method that you are calling trying to return a collection?
Maybe it's being called but not getting the collection. Check the log
file or maybe the stnd out on the console for more specifics on where
the error is occurring and for other details.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
Its not about the inner workings, its about what it does. Sure struts action and jsf do this differently. Having all the stuff you need available in FacesContent.currentInstance() rather than having form,mapping, request and response passed to actions, yes these are differences. But are the differences so profound that you need to tell folk that there are no similarities? What they both have in common is that jsf and struts action provide a means of validating input and then forwarding to the next view. If you look at the patterns that your so keen on quoting (albeit not explaining) then its not that hard to see that both are front controllers. In struts mapping are done via url patterns, in JSF expressions. Yes this is a difference, but one analogous to VB and C++? I don't think so or I dont get it. I use both struts action and JSF, and I don't get what you're on about. If the motivation behind JSF is about creating IDE friendly stuff then so be it, but you cant have used JSF and claim its painful to develop without one. I don't care what the motivations behind the spec are, I'm more concerned with something that works for a given problem. Again you're claiming that a road is made with cars rather than for them. Mark On 1/8/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > See within: > > On 1/7/06, Mark Lowe <[EMAIL PROTECTED]> wrote: > > > > Both struts and jsf provide a means of handling form submissons, that > > seems pretty view controller to me. > > > ANY framework has to provide a "means" of handling form submissions. That > has nothing whatsoever to do with controllers, view controllers, or > whatever. Check out > http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html. > > > > > I dont get how everything's so > > black and white and/or chalk and cheese. > > > I have no idea what this is talking about. I certainly don't think anyone > who sees what is going on thinks that the controller mechanism in Struts is > anything like that in JSF. That is a huge confusion that makes no sense. I > cannot even imagine how one would get to that wrong-headed position. I do > know that the page-centric boys early on in JSF decided to talk like a view > controller in their scheme of things was like a real controller, but that > was poopooed ad abnitia. > > > Sure you define views in jsf, > > and you can mess with more than just the forms, but are the > > differences really as profound or their similarities really comparable > > to VB and C++? Sorry I dont get it. When coding jsf and struts struff > > I get the feeling that I'm being abstracted from the servlet spec. > > > > Apparently you don't know how these things work. If you did, their huge > differences would be and have to be immediately apparent. > > > What IDE vendors do is their affair, they've been trying to make > > coding brain dead for years and I doubt thats going to stop (note: I'm > > not saying that if someone uses an ide s/he is brain dead). But thats > > how JSF and struts are supported by IDE vendors not what they are in > > themselves, is a motorway made with tarmac or cars? > > > You don't get it, Mark. VB was made for the IDE vendors and SO WAS JSF, in > order to try a sort of competition with the .NET vendor yearning. This is > not a case where the IDE people are off on the sidelines playing their own > game. WIthout the IDE stuff, JSF is pretty much junk. No one seriously > thinks it is better on the merits of how it works. At least I hope no one > is that deluded. It will be better, if at all, based on its ease of use for > people without many skills. > > > Like i said before, C++ and VB like struts and jsf, sorry I'm trying > > to get it but I'm not there yet.. While I know there are differences > > between jsf and struts, I dont think they are as profound as you've > > stated. > > > I think you have to go look at how they are built. Surely you don't know > or you could not say this, Mark. They are night and day. That is not even > a debate in my opinion. The hope early on was for JSF to obfuscate this > difference so it could purloin the Struts good name. That worked to a > certain extent. > > > > Amen, brother. I wish Mark would see this. > > > > So do I, I guess I'll have to keep at it, and maybe one day I can > > become just like you :o) More seriously I'd really like what I'm > > missing clarifed as there's obviously something I haven't understood. > > > > Mark > > > Again, apparently you just don't have a knowledge of the basic workings of > the two frameworks. > > > > On 1/7/06, Dakota Jack <[EMAIL PROTECTED] > wrote: > > > Amen, brother. I wish Mark would see this. > > > > > > > > > On 1/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote: > > > > let me assure you VB isnt the only course designed for tech support > people > > > > wedged between auto-shop and recess > > > > yesterday I was prevented from implementing a script because the > > > individual > > > > didnt want
Noob Q: "Failed to obtain specified collection"
Quick question - what's this _actually_ mean? It's obviously found the
field, because if I change the reference in the JSP to something wrong,
it gives me a different error ("No getter found" or something similar).
Makes no real sense to me. Where should I look for my mistakes? I've
added bean references at the top of the JSP, they seem OK and don't
trigger any errors.
Cheers,
-Josh
--
"His comrades fought beside him, Van Owen and the rest...
But of all the thompson gunners- Roland was the best."
Josh McDonald
Analyst Programmer
Information Technology
Ph: 61 7 3006 6460
Email: [EMAIL PROTECTED]
***
Messages included in this e-mail and any of its attachments are those
of the author unless specifically stated to represent WorkCover Queensland. The
contents of this message are to be used for the intended purpose only and are
to be kept confidential at all times.
This message may contain privileged information directed only to the intended
addressee/s. Accidental receipt of this information should be deleted promptly
and the sender notified.
This e-mail has been scanned by Sophos for known viruses.
However, no warranty nor liability is implied in this respect.
Re: [OT] was Re: Advice for Struts expert ...
Ted Husted wrote: How about [FRIDAY] You might be a Dogbert if ... ... you are inspired by Internet trolls. :) * Gentle Definition - http://www.askdavetaylor.com/whats_a_troll_and_a_zombie.html * Definitive Definition - http://en.wikipedia.org/wiki/Internet_trolls * A shorter, slightly less definitive definition - http://uncyclopedia.org/wiki/Trolls -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jason Lea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] was Re: Advice for Struts expert ...
Ted Husted <[EMAIL PROTECTED]> wrote on 01/08/2006 02:00:25 PM: > How about > > [FRIDAY] You might be a Dogbert if ... > > ... you are inspired by Internet trolls. :) > > * Gentle Definition - > http://www.askdavetaylor.com/whats_a_troll_and_a_zombie.html Actually there's an even gentler defintion (which, frankly, was what I had assumed the original poster might've meant) - take this definition (from dictionary.com): "a partsong in which voices follow each other; one voice starts and others join in one after another until all are singing different parts of the song at the same time". Certainly this discussion could be thought of different parts of the same song..:) > * Definitive Definition - http://en.wikipedia.org/wiki/Internet_trolls > > -Ted. > Geeta
Re: Advice for Struts expert wanting to try Shale?
Just a small correction below : On 1/8/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > I am developping a navigation panel like the panel2 from tomahawk (I > had to offer some more features) and I like the way you can embedd > some navigation items tags (NavigationItem, NavigationItems) inside > the navigation tag to specify the different elements of the panel. > Since the navigation model elements need some more attributes then > SelectItem like an action attribute (supporting MethodBinding of > course), you end up developping some custom models elements just > adding some more attributes. I think this part is alright, I don't > want to use something generic like DynaFormBean in Struts but I think > some base model elements could be standardized like a base class Item > and some subclasses like SelectItem and ActionItem (I read somewhere > there something similar in Oracle ADF components, maybe I should take > a look). > > The problem I see here is you have to implement for each kind of > model, two custom UIxxxItem and UIxxxItems components so you can end > up with a lot of redundant UI components. This problem is quite > familiar in the OO world and it is usually solved elegantly by the > Bridge pattern, where here model elements are the abstraction > hierarchy and the UIxxxItem and UIxxxItems are the > implementations specific. I mean the inverse, he UIxxxItem and UIxxxItems are the abstraction hierarchy and the model elements the implementation hierarchy. >So what I would like is to be able to always use the same UI > components to specify the model of a parent UI component. What I am > doing right now, is whenever a component have a model defined by child > elements, it implements a custom interface having a method returning > the model class it supports and making sure all model elements have a > constructor taking a properties map as an input (in case the element > must be built from the UIxxxItem properties). Then I have developped a > custom iterator capable of going throught any UI component model > implemented by those standard model UI components. Maybe someone have > a better design to propose me but it seems to do the trick for the > moment. What do you think? > > Of course with JSP you need to developp a lot of custom tags but I > guess not with Clay or facelets :)) > > Here's the link to the Tomahawk panel I was refering to : > http://www.irian.at/myfaces/panelnavigation_2.jsp.source > > On 1/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Just a couple of comments intermixed below. > > > > On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > > > Ok can we all ignore the troll and go back to the original subject... > > > > > > Like Craig pointed out Rick, I think you should play around with JSF > > > first and then Shale. > > > The IBM serie "Cleared FUD about JSF" is a good introduction to. I > > > think one of the previous poster posted the link. > > > > > > Shale is decomposed in modules so it not so hard to get a grab on the > > > functionalities, one type at a time. Actually, it's not very complex > > > except maybe the Clay plugin wich does require some time to understand > > > but using it or Facelets instead of JSP is worth the troubles in my > > > opinion. > > > > > > Anyway, I have been playing with JSF for sometimes now and here's the > > > various differences against Struts I've found : > > > > > > - ActionForm and Action (more Dispatch Action in fact) are replaced by > > > backing beans. > > > No more copy between ActionForm and Domain objets or data transfer > > > objects are necessary. > > > > > > -The event model is fine-grained instead of coarse-grained. In struts, > > > you don't have a true event model and the only event is receive a > > > request and the *listeners* Action, are application wide. > > > > > > In JSF, the basic event listener are registered on a single component > > > instead of the complete application. You have two basic different > > > events (ActionEvent and ValueChangeEvent) and the event listeners all > > > receive an event object representing the event context. > > > > > > While these are the only two events defined in the standard, it is perfectly > > feasible for JSF components to define their own events, and their own event > > handlers, using the same basic infrastructure. > > > > Plus, in JSF > > > you can register more then one listeners on a component so no need for > > > Action chaining and the troubles coming along with it. Note that the > > > action events listeners are not responsible to choose the next view > > > like the actions are in Struts. It's quite a change but you get used > > > to it very fast in the end and this way your backing beans (most of > > > the time, they are the action listeners) are easier to reuse. Overall, > > > you can understand this quite fast if you are use to program Swing > > > applications. > > > > > > I actually wish there wasn't be so much difference here :-(. In the > > original v
Re: double submit problem
I can't speak to Struts Dialog, but in a typical Struts application you can guard against double submits by calling saveToken(request); in the "prepare" action that displays the form for editing. In the "process" action that handles the save, check boolean tokenValid = isTokenValid(request); isTokenValid(request) to see if a double submnit happened. -- HTH, Ted. http://www.husted.com/poe/ On 1/6/06, Rafael Taboada <[EMAIL PROTECTED]> wrote: > Hi folks... I'm trying to solve my problem when an user submit a form and he > clicks the submit button more than twice. > > My app runs perfect... I mean, It saves data. But in this case, it saves > data as many clicks the user does. > > Do u know how I can solve that? > > I'm trying to use Struts Dialog: > http://struts.sourceforge.net/strutsdialogs/dialogaction.html > > I implemented an app using that but it still has the same problem... why? > maybe I'm doing something wrong??? I followed the login sample. But in my > case I have a NewData module. > > 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: Advice for Struts expert wanting to try Shale?
Trollomic? Combination of Troll and Comic? One who is a troll and yet makes you laugh at the same time? Frank [EMAIL PROTECTED] wrote: "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote on 01/08/2006 11:29:54 AM: Gary VanMatre wrote: Very interesting, and only if as much intellectual collateral was spent addressing technical issues... Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL Frank Which certainly suggests a new entry for the "you are a geek if .. " :)) Geeta -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] was Re: Advice for Struts expert ...
On 1/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Which certainly suggests a new entry for the "you are a geek if .. " :)) How about [FRIDAY] You might be a Dogbert if ... ... you are inspired by Internet trolls. :) * Gentle Definition - http://www.askdavetaylor.com/whats_a_troll_and_a_zombie.html * Definitive Definition - http://en.wikipedia.org/wiki/Internet_trolls -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Push Technology
Try xmlsocket in Flash.
Put javascript calls in xmlsocket.onData(){}
On 1/5/06, souravm <[EMAIL PROTECTED]> wrote:
Re: Advice for Struts expert wanting to try Shale?
"Frank W. Zammetti" <[EMAIL PROTECTED]> wrote on 01/08/2006 11:29:54 AM: > Gary VanMatre wrote: > > Very interesting, and only if as much intellectual collateral was > spent addressing technical issues... > > Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL > > Frank Which certainly suggests a new entry for the "you are a geek if .. " :)) Geeta
Re: Advice for Struts expert wanting to try Shale?
Gary VanMatre wrote: Very interesting, and only if as much intellectual collateral was spent addressing technical issues... Oh come on now Gary, that wouldn't be even HALF as entertaining;) LOL Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which AJAX library?
Dear Frank Thank you very much for your pointers. A good starting point. Fred -- Forwarded message -- From: "Frank W. Zammetti" <[EMAIL PROTECTED]> To: Struts Users Mailing List Date: Sat, 07 Jan 2006 00:29:33 -0500 Subject: Re: Which AJAX library? Fred So wrote: > There are many AJax libraries available at the moment. Which one do you > think works best/most natually with Struts? Hi Fred, I think to answer that you have to determine what your needs are. Your right, there are a lot of choices, but each has a fairly different focus, even though they obviously have a lot in common. Off the top of my head, the ones I'd consider: * AjaxTags in Java Web Parts (http://javawebparts.sourceforge.net) - Of course I'd list my own first :) Seriously though, if what your looking for is an easy to integrate solution that deals with the client-side but leaves the server-side to you, AjaxTags may be of interest. It's a completely declarative approach to Ajax (i.e., all driven by XML config file) that comes in the form of a taglib (with a grand total of four tags, two of which you may not use much). AjaxTags won't give you canned solutions, i.e., it isn't about UI widgets or pre-made dropdown suggestion boxes, but it will facilitate you building those with a minimum of fuss, plus a lot more. * Dojo (http://dojotoolkit.org/) - This one is growing in popularity, and for good reason. It offers more than just the mechanisms for making Ajax calls. Widgets are a big part of it, as is animations, as well as "extensions" to Javascript to make your life easier. It has a much wider focus, but what is coming out of the project has looked very good so far. * DWR (http://getahead.ltd.uk/dwr/) - This one actually has some information specifically about integrating with Struts on the site. DWR in interesting in that it is literally a remote procedural call mechanism whereby you can call Java code from Javascript. DWR even handles marshalling and unmarshalling of data types between Java and Javascript. There are plenty of others of course, but those are the three I would personally look at first. As you can see, they all have a different focus, some offering a wider range of things than others. They can all be used with Struts apps, with varying degrees of complexity. So, it depends on what you are trying to do. If your goal is to be able to fire some Ajax requests at your server based on various events with a minimum of fuss, AjaxTags might be the ticket. If you are looking for some fantastic Ajax-based UI widgets (this one tends to impress people the most, although there was a better one a while back: http://archive.dojotoolkit.org/nightly/tests/widget/test_FisheyeList.html), check out Dojo. If you need a more "full-stack" solution for calling remote code, DWR might be perfect. Hope that helps! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED]
Re: Advice for Struts expert wanting to try Shale?
>From: Dakota Jack <[EMAIL PROTECTED]> > > Just so you know, Alexandre Poitras, and others with similar tendencies, > calling someone a "troll" in a professional setting having to do with their > occupation almost certainly is an actionable per se libel with presumed > damages and linking the person doing the libel to any and all jurisdictions > covered by this list. Actually, I've always thought of this kind of troll http://www.pitt.edu/~dash/type0122e.html >This is not a chat room where idiocies and loose talk > are the common fare. This is a professional setting. I would keep that in > mind if I were you. This is not some free-fire zone where you can treat > people outside the law. If you have your opinions, that is well and good. > Don't negate mine with statements like this unless you want to have to prove > the matter in a court of law. This is made public rather than to you > personally to give other similarly lacking in enlightenment fair warning. > Sorry to have to discuss something other than the issues. > Very interesting, and only if as much intellectual collateral was spent addressing technical issues... > On 1/7/06, Alexandre Poitras wrote: > > > > Ok can we all ignore the troll and go back to the original subject... > > > > Like Craig pointed out Rick, I think you should play around with JSF > > first and then Shale. > > The IBM serie "Cleared FUD about JSF" is a good introduction to. I > > think one of the previous poster posted the link. > > > > Shale is decomposed in modules so it not so hard to get a grab on the > > functionalities, one type at a time. Actually, it's not very complex > > except maybe the Clay plugin wich does require some time to understand > > but using it or Facelets instead of JSP is worth the troubles in my > > opinion. > > > > Anyway, I have been playing with JSF for sometimes now and here's the > > various differences against Struts I've found : > > > > - ActionForm and Action (more Dispatch Action in fact) are replaced by > > backing beans. > > No more copy between ActionForm and Domain objets or data transfer > > objects are necessary. > > > > -The event model is fine-grained instead of coarse-grained. In struts, > > you don't have a true event model and the only event is receive a > > request and the *listeners* Action, are application wide. > > > > In JSF, the basic event listener are registered on a single component > > instead of the complete application. You have two basic different > > events (ActionEvent and ValueChangeEvent) and the event listeners all > > receive an event object representing the event context. Plus, in JSF > > you can register more then one listeners on a component so no need for > > Action chaining and the troubles coming along with it. Note that the > > action events listeners are not responsible to choose the next view > > like the actions are in Struts. It's quite a change but you get used > > to it very fast in the end and this way your backing beans (most of > > the time, they are the action listeners) are easier to reuse. Overall, > > you can understand this quite fast if you are use to program Swing > > applications. > > > > - The binding mechanism is way more powerful then Struts one and I > > think this is where JSF really shine. In struts, you could only match > > form beans properties to forms html tags and it was complex to bind > > complex forms. In JSF, you can use EL value bindings or method > > bindings expressions. It is really great in my mind and very simple at > > the same time, thank to IoC and managed beans. > > > > - Finally, JSF has a component model and so reusing is very easy. The > > components hide most of the complexity to the developper (ugly > > javascript for exemple). Learning to developp components is what take > > time to learn, but you can get started quite fast if you just want to > > use it first. At least, there are a lot of exemples available. > > > > - One last thing, since the data and method bindings are specified in > > the "jsp/html/whatever technologie you use for view" page and the > > navigation is specified globally in the configuration file (not per > > action like in Struts), it is quite easy to follow the application > > flow. It was something that was annoying me sometimes with Struts, lot > > of places to look to find where the executed code is located. > > > > I hope it's help and since I am far from considering me a JSF expert, > > anyone can feel free to correct me. And please be tolerant about my > > english since I am not a native speaker and it's quite a long post :) > > > > On a side note for people having experience developping custom > > components, what annoys me so far in JSF is the model package, in fact > > the SelectItem class. There are no model objets for action components > > (like you need for a menu or navigation panel) and no universal > > components (UISelectItem and UISelec
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Rahul Akolkar <[EMAIL PROTECTED]> wrote on 01/08/2006 12:43:40 AM: > > Not really. I understand your "specs" now, whats the "nasty error" you > refer to, does that hold any clues? Ok, so after reading your post and Craig's subsequent reply, I realised that it is ok to return a "null" from the bean action and Shale would act in the "usual" way. I was earlier returning the actual name of the view id i was on and that was what was the problem. Returning null solved that problem and my dialog works without the cludgy "different name" i thought I needed..:) > A couple of things that I think are relevant here: > > * A self transition for a view state should be possible (its > definitely legit in state chart theory, Shale dialogs being state > charts for a specific purpose). Yes, as I note above, it was "stupid user" kind of error. > > * I tend to use action states since I can visualize the processing > bits as states in the dialog config (and searching definitely > qualifies), and the corresponding multiple logical outcomes (error, no > results, few results, many results) appear as transitions in the > action state. But, I understand this is subjective. Ok... > > There is nothing wrong with "common" transitions -- Shale calls these > global transitions -- pending they're truly common. Looking at what > you have listed: > > * Transitions such as the first one (cancel) are useful when > specified as global transitions, especially in wizard style dialogs, > otherwise you'd be authoring them redundantly. > > * The second one is a candidate for localizing (will be a side-effect > of having one view state). Yes, I see now. Though returning "null" now obviates this for me now. > > * The third one I believe is refering to the "always clickable" menu > bar link to initiate the search dialog, and that is going to be > suspect since Shale dialogs, as of today, work best when you run a > dialog to completion before beginning another (where completion is > defined as reaching an end state, that says nothing about any *task* > being completed). Ofcourse, if you're using dialogs, it'd be good be > aware of the known issues 35066 [1], 37120 [2] and 37571 [3], if > you're not already. Ah, this is a bad thing for me..(:( I really absolutely have to have an always visible and always clickable menu bar and after reading the bugzilla notes seems like "breaking out of" a current dialog and starting abrand new one without formally ending it is not possible now (hope I have that right?). So i will either cludge a solution or stay my use of dialogs till you guys have figured out the right solution. > > And finally, use the latest nightlies if you can, just saw r366984 [4] > whiz by, that added better error messages for dialogs. I am working with the Jan 6th nightly. But as you point out that is way dated.;) > > > > > > -Rahul Yet once more, many many thanks for your time. I really appreciate it. Geeta
Re: Advice for Struts expert wanting to try Shale?
Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a "troll" in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. I would keep that in mind if I were you. This is not some free-fire zone where you can treat people outside the law. If you have your opinions, that is well and good. Don't negate mine with statements like this unless you want to have to prove the matter in a court of law. This is made public rather than to you personally to give other similarly lacking in enlightenment fair warning. Sorry to have to discuss something other than the issues. On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > Ok can we all ignore the troll and go back to the original subject... > > Like Craig pointed out Rick, I think you should play around with JSF > first and then Shale. > The IBM serie "Cleared FUD about JSF" is a good introduction to. I > think one of the previous poster posted the link. > > Shale is decomposed in modules so it not so hard to get a grab on the > functionalities, one type at a time. Actually, it's not very complex > except maybe the Clay plugin wich does require some time to understand > but using it or Facelets instead of JSP is worth the troubles in my > opinion. > > Anyway, I have been playing with JSF for sometimes now and here's the > various differences against Struts I've found : > > - ActionForm and Action (more Dispatch Action in fact) are replaced by > backing beans. > No more copy between ActionForm and Domain objets or data transfer > objects are necessary. > > -The event model is fine-grained instead of coarse-grained. In struts, > you don't have a true event model and the only event is receive a > request and the *listeners* Action, are application wide. > > In JSF, the basic event listener are registered on a single component > instead of the complete application. You have two basic different > events (ActionEvent and ValueChangeEvent) and the event listeners all > receive an event object representing the event context. Plus, in JSF > you can register more then one listeners on a component so no need for > Action chaining and the troubles coming along with it. Note that the > action events listeners are not responsible to choose the next view > like the actions are in Struts. It's quite a change but you get used > to it very fast in the end and this way your backing beans (most of > the time, they are the action listeners) are easier to reuse. Overall, > you can understand this quite fast if you are use to program Swing > applications. > > - The binding mechanism is way more powerful then Struts one and I > think this is where JSF really shine. In struts, you could only match > form beans properties to forms html tags and it was complex to bind > complex forms. In JSF, you can use EL value bindings or method > bindings expressions. It is really great in my mind and very simple at > the same time, thank to IoC and managed beans. > > - Finally, JSF has a component model and so reusing is very easy. The > components hide most of the complexity to the developper (ugly > javascript for exemple). Learning to developp components is what take > time to learn, but you can get started quite fast if you just want to > use it first. At least, there are a lot of exemples available. > > - One last thing, since the data and method bindings are specified in > the "jsp/html/whatever technologie you use for view" page and the > navigation is specified globally in the configuration file (not per > action like in Struts), it is quite easy to follow the application > flow. It was something that was annoying me sometimes with Struts, lot > of places to look to find where the executed code is located. > > I hope it's help and since I am far from considering me a JSF expert, > anyone can feel free to correct me. And please be tolerant about my > english since I am not a native speaker and it's quite a long post :) > > On a side note for people having experience developping custom > components, what annoys me so far in JSF is the model package, in fact > the SelectItem class. There are no model objets for action components > (like you need for a menu or navigation panel) and no universal > components (UISelectItem and UISelectItems) for specifying the model. > You need one for each component and it is quite a pain in the a.. to > code those again and again. Anyway, it always possible to develop your > own model hierarchy and use an adaptor to make SelectItem compatible > with it. As anyone had the same problem so far? If it is the case, > maybe a solution could be part of the future commons-jsf package that > have been discussed in the past. I am working on something around this >
Re: Advice for Struts expert wanting to try Shale?
On 1/7/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > An expert uses the best tool for the job. A journeyman wants one size > > to fit all. > > Blessed are those who get to make such decisions. There are > unfortunately many shops that decide what the proper technologies are > *before* any project kicks off, all in the name of "standardization". And some shops even standardize on details like which IDE everyone *must* use. :) Happily, before long, an enterprise will be able to standardize on Apache Struts, and some lucky developers will be able to at least choose the best Struts tool for the job. Perhaps one day we won't have to type cast every problem as a nail. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Concrete examples (was Re: Advice for Struts expert ...)
On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Concrete examples will help make this clearer, +1 When it comes to application development, I believe concrete examples are the best way for us to say what we mean. Struts has always shipped with an example or three of its own. Five years later, we have several concrete examples of Struts applications living in the wild. For example, Roller is a popular, scalable Struts application * http://www.rollerweblogger.org/page/project that powers the infamous JRoller site * http://jroller.com/ and is now going through the Apache incubator * http://incubator.apache.org/projects/roller.html Under SourceForge, XPlanner and LogWeb (among others) are powered by Struts * http://www.xplanner.org/ * http://www.codeczar.com/products/logweb/index.html It might be interesting to start taking a closer look at projects like these, and perhaps start our own patterns catalog and cookbook, based on what we see happening in production applications, like these. The best part is that because these are open source projects, we also have the opportunity to look for places where things might be done better, and contribute back some patches of our own. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
