|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
|
Message #154782
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Apache announces new sub-project of Struts: Shale
Please help clear this up for me. Is JSF an actual library/package or just a specification which Shale plans on implementing?
Or, alternatively - should I read up on general JSF stuff before I go and start checking out Shale?
|
|
|
Message #154783
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
I guess not one of the 3 posts above read what the announcement said.
Struts added a project, that's all. It be like saying... there is now a new tag lib.
Struts(classic) 1.3 is majority a new re-write based on CoR, another simple but powerfull technology(again, developer by Carig M.). It should allow Struts to catch up to some advantages of competing frameworks.
There was some debate about who should host Shale, MyFaces or Struts; but it realy does not matter.
Struts development is fine, I think at the fastest pace ever. You can look at Dice and see help wanted % of Struts vs XYZ. When ever another framework ships, they say: We are better than Struts. So ... one could argue Struts is the standard. But you don't have to use #1, you should use what you think is best.
When one 1.3 ships, you can decide if you like Struts, or alternatives.
.V
|
|
|
Message #154787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Please help clear this up for me. Is JSF an actual library/package or just a specification which Shale plans on implementing?Or, alternatively - should I read up on general JSF stuff before I go and start checking out Shale?
JSF is a specification that works in conjuction with JSP technology as provided by Sun (http://java.sun.com/j2ee/javaserverfaces).
JSF's primary concern is in user interface components and doesn't provide much for controller features. This is where frameworks like Struts (Shale) steps in. Shale will be able to concentrate on controller behavior, leaving presentation concerns up to JSF implementations (Sun's JSF-RI and Apache MyFaces-- take your pick).
Jacob (JSR 252 EG)
|
|
|
Message #154796
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
JSF is a specification that works in conjuction with JSP technology as provided by Sun (http://java.sun.com/j2ee/javaserverfaces).
Nope it is a user interface framework that can work in conjunction with JSP.
JSF's primary concern is in user interface components and doesn't provide much for controller features. This is where frameworks like Struts (Shale) steps in. Shale will be able to concentrate on controller behavior, leaving presentation concerns up to JSF implementations (Sun's JSF-RI and Apache MyFaces-- take your pick).Jacob (JSR 252 EG)
What? JSF provides a event handling mechanism that is both more sophisticated and more user friendly than the primitive "controller logic" that we have seen in systems like Struts.
By all means, something like JSF should have replaced Struts for good. It is only the slowness of the JCP that has left us with inferior tools compared to the .NET camp. Oh well, there is always Tapestry :-)
|
|
|
Message #154801
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Nope it is a user interface framework that can work in conjunction with JSP.
Of course, I never said it only works with JSP-- just trying to answer Joe's question within the realm of his understanding of Struts as a web framework.
If you were to parallel technologies such as Swing, AWT, or SWT to JSF, they all provide similar intentions or functionality (events, rendering, etc). From a controller standpoint, Struts provides a stronger feature-set in managing workflows and exception handling (features that current Struts developers are used to, which although JSF can handle, it doesn't intrinsically emphasize).
|
|
|
Message #154808
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Please help clear this up for me. Is JSF an actual library/package or just a specification which Shale plans on implementing?
JavaServer Faces is a specification, just like Servlet, JSP, JSTL, and so on. There can be several implementations -- two that are widely referred to are the Reference Implementation (RI) from Sun, which was delivered along with the original spec (and is available, including source, at java.net), and MyFaces, an open source implementation in Apache's incubator that is striving to create a compatible implementation (but they haven't completed that task yet).
Shale does not intend to implement JSF -- it intends to provide value added framework capabilities around an existing JSF implementation (and it works with either the RI or MyFaces, for example). This makes sense when you understand that JSF is focused on the view tier, while Shale (as is also the case with Struts 1.x) is more concerned about the controller tier. JSF's APIs provide numerous extension points designed to allow this kind of add-on, and Shale is leveraging them.
Or, alternatively - should I read up on general JSF stuff before I go and start checking out Shale?
A great starting point for JSF information is a web site maintained by Kito Mann: http://jsfcentral.com
Craig McClanahan
|
|
|
Message #154822
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
So in order to use on framework (JSF) we need another one (Shale)? Why it could not be a part of JSF? or MyFaces? Marina
IMHO, that's the beauty of JSF. JSF works with plain Java Objects-- so you don't have to extend Actions or ActionForms. This means that other frameworks such as WebWork, Struts, etc can integrate with JSF's presentation capabilities.
This *also* means that you can roll your own controller capabilities that are specific to your application without concerning yourself with things such as navigation handling, state managemennt, validation, and conversions as JSF already includes those capabilities.
Ideally, JSF is capable enough that you don't need a full framework to implement your application's concerns. For those development groups who are looking for a pre-packaged, standard controller framework with all the bells and whistles, Shale will probably be the tool of choice.
|
|
|
Message #154831
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
I still don't understand why Apache did a name change? It seems to be that they want Shale to be totally different from Struts (even though from reading artcles they don't want to admit it). It's almost similar to these stores we have in Brooklyn: one day they open as "Habib's Market" and next month it's "Mula's Market" and then...you get the idea. When someone changes the name they want to be totally different from the previous.
But back to Struts, don't we have here a birth of a similar formula:
Struts + JSF = Tapestry
Just a thought....
|
|
|
Message #154835
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
don't we have here a birth of a similar formula:Struts + JSF = Tapestry Just a thought.... It looks like actual equation is something like this:
Struts + JSF + JavaStudioCreator = Tapestry - (Components Templating) - (Developer|designer independence)
|
|
|
Message #154842
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
don't we have here a birth of a similar formula:Struts + JSF = Tapestry Just a thought.... It looks like actual equation is something like this:Struts + JSF + JavaStudioCreator = Tapestry - (Components Templating) - (Developer|designer independence)
Want to do components templating with HTML a la Tapestry in JSF? here is how.
Regards,
Henrique Steckelberg
|
|
|
Message #154844
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
I still don't understand why Apache did a name change?
No name change. They are 2 diferent things:
Struts everyone knows, use w/ JSTL, Velocity, XSLT, etc; like before. Now it has a CoR.
Or ...
Shale, you can use w/JSF, DHTML XML-RPC and some of the above.
WebWorks, you can use w/....
You get the idea.
What may be confusing people is that Sturts (a top level ASF project) you can download 2 different MVC frameworks.
Why not? May the best one win more market share and produciton popularity.
It seems to be that they want Shale to be totally different from Struts
Yup, 2 diferent things w/ 2 diferent code base.
Sort of like why don't the call an Airplane a Car. They both travel, but they are diferent and have 2 names.
.V
|
|
|
Message #154848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
I already asked this in the different thread, and was not answered, so I will ask again: why Craig thinks that input->controller->model->view->output sequence is less developer-friendly than a "single Java class, implicitly associated in a 1:1 relationship", combining the "tightly coupled processing actions"? Am I mistaken, or this will impose using of one solid module for both input and output? So, if I need to change only input or only output, I would have to create a new module? Is this good for code reuse? Current Struts approach, where "the setup logic and processing logic end up in two different Actions" (which, by the way, is not advertised as a standard practice on Apache web-site) is far more flexible and allows to separate input from the output and to create truly stateless views.
The only fact that MS went Page Controller route does not mean this is the proper way to do things. MS is adding built-in Front Controller pattern to asp.net 2.0, this is the feature that Struts has from the beginning. Yes, Struts is tightly related to http classes, and its testing maybe not as easy as it could be, but let us not throw out the baby with the water. The basic concept of Struts of having the Controller to accept input, and the possibility to respond with different Views, is its best asset.
MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.
|
|
|
Message #154861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
I already asked this in the different thread, and was not answered, so I will ask again: why Craig thinks that input->controller->model->view->output sequence is less developer-friendly than a "single Java class, implicitly associated in a 1:1 relationship", combining the "tightly coupled processing actions"? Am I mistaken, or this will impose using of one solid module for both input and output? So, if I need to change only input or only output, I would have to create a new module? Is this good for code reuse? Current Struts approach, where "the setup logic and processing logic end up in two different Actions" (which, by the way, is not advertised as a standard practice on Apache web-site) is far more flexible and allows to separate input from the output and to create truly stateless views.
Four years of following the Struts user mailing list (many MANY thousands of postings) indicates that the complexity of getting all of these moving parts coordinated is the single hardest part of learning how to build a Struts based application. Like any good open source developer, I'm listening to where the users of my framework have pain, and I'm going to do things to make life better.
Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue -- but their needs are just as legitimate as the needs of people who like O-O and code reuse and all of that sort of stuff.
Note that you are not going to hear any bashing from me about frameworks that cater to professional software developers who understand deep design patterns. If that is your gig, stick with Struts 1.x or WebWorks or whatever. But there are orders of magnitude more people in the world that don't get it, and ignoring them is not what I am interested in.
The only fact that MS went Page Controller route does not mean this is the proper way to do things. MS is adding built-in Front Controller pattern to asp.net 2.0, this is the feature that Struts has from the beginning. Yes, Struts is tightly related to http classes, and its testing maybe not as easy as it could be, but let us not throw out the baby with the water. The basic concept of Struts of having the Controller to accept input, and the possibility to respond with different Views, is its best asset.MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.
While it is indeed possible for Struts apps to generate different views from the same input, that is NOT what 99% of the world actually does with it -- they generate apps that have static paths through the control flow, and are therefore tempted to bend the basic Struts architecture by chaining Actions. Shale makes that sort of application SUBSTANTIALLY easier to build. All the logic associated with pulling data from the model is in the same class as the logic to push the results back to the model (which is particularly useful in the not-uncommon case where you keep refining the same view over and over again). However, the physical representation of that view (what HTML gets generated, etc.) is still separated from the event handlers needed to interact with the model tier.
Note also that Shale does not forsake the "every request flows through the controller" model -- that's handled by a Filter that lets you customize the overall architecture to your heart's content. Indeed, I was able to add support for the server side of applications that need remoting support (such as clients that use XmlHttpRequest) without impacting the flow for server side trips that invoke user interface actions. You're free to do the same sorts of decoupling of input processing and producing the subsequent response that you can do with classic Struts, if that is what you want.
Finally, even if your "unmanageable mess" assertion were true (something I am not prepared to stipulate), the very large majority of the applications that have ever been built with Struts are smaller than that, so it would be pretty much irrelevant to most Struts users.
Craig
PS: It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements.
|
|
|
Message #154871
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.
Off-topic here, but whenever I read comments like the above I find it very depressing. If you compare something like Tapestry with ASP.NET, it's remarkable how similar they are, yet they were conceived and developed entirely independently. A case of two sets of clever people (one person, in the case of Tapestry) coming up with almost exactly same solution to a problem (the simplification of web user interface development).<br>Whenever someone complains about a framework being too easy for serious use, it rings alarm bells with me.
|
|
|
Message #154921
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Craig
PS: It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements.
Or, the quote I have above my monitor, "Philosophical purity leads to pragmatism"
Struts was the best approach to web design when it came out, others (just like in web design) have since built off those ideas and figured out what works and what doesn't for them. WebWork does a better job handling logic/flows at the server side and Tapestry has a great interface component model. Each framework, as far as I know, is an all in one solution that developers 'lock' their whole web application into.
As a reflection of programming practices, I'm sure you will start to see more projects that only concern themselves with a small subset of responsibilities (SRP). JSF is one of those projects as it works to standardize itself within one responsibility. Other frameworks, like Shale, could only concern themselves with the responsibilities of a controller.
In addition, this seperation allows developers of varying degrees of knowledge to concentrate on specific parts of the application, using the best tools possible. For JSF, it might be any vendor suite (IBM, BEA) or Sun's Creator to quickly build UI's. While the more advanced programmer can sit in their favorite IDE and hack out their own, best of breed controller or go with something like Shale. Lastly, progressive web standards allows a web designer to use CSS to decorate standard component models produced by JSF vendors.
I do agree that developers have learned a lot about what works and what doesn't since Struts first hit us. In no way should we argue against any framework and just feel lucky that as Java programmers, we have lots of choice.
-Jacob
|
|
|
Message #154926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy. Funny, but all Strut apps that I have seen have the same "unmanageable mess" issue (granted, I have not seen all Struts apps in existence :) ). Yes, they may be more flexible, but at a high price. The problem with ASP.Net is that it still holds to the page paradigm. And that it has no servlet equivalent.
With JSF, things are views with things responding to events. At first glance, it looks like things are less spread out than with Struts.
Btw, anyone see Alan Holub's comments on Struts in this weeks SD Times? Pretty much my thoughts exactly.
|
|
|
Message #154942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements. In no way should we argue against any framework and just feel lucky that as Java programmers, we have lots of choice. Well, I would agree with "choice is good" thing. But seems that I prefer to use hammer for everything ;)
MSDN on Page Controller: "The key constraint of Page Controller is that you create one controller for each Web page. This works well for applications with a static set of pages and a simple navigation path. Some more complex applications require dynamic configuration of pages and navigation maps between them."
MSDN on Front Controller: "The Page Controller solution describes a single object per logical page. This solution breaks down when you need to control or coordinate processing across multiple pages. ... Because Page Controller is implemented with a single object per logical page, it is difficult to consistently apply a particular action across all the pages in a Web application. ... The association of the URL to the particular controller object can be constraining for Web applications."
Basically, Front Controller allows to do everything Page Controller does, and more. Yes, with added complexity. I like unversal solutions, but maybe it is just me.
|
|
|
Message #154943
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
things were better before
development).<br>Whenever someone complains about a framework being too easy for serious use, it rings alarm bells with me.
Too much of one up manship in Java world.
These frameworks are all the rage these days but think about a poor new programmer who has to learn
1. Java
2. http
3. html
4. strut
5. JSF
6. etc etc
added to that new releases of api's and all this in the name of making things easier. You must be dreaming. I think things were better when we wrote our own simple frameworks using the core API. Struts is not that clever after all.
|
|
|
Message #154945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue...
It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?
|
|
|
Message #154946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Curse of Emare: Struts in Exile
As Rod Johnson (Spring) says Struts is request-driven web MVC and JSF (Shale) is page-centric RAD (rapid development with tools as in VB). JSF is built for tools and for people that are code-challenged. Combining them is a mere market ploy signaling that the Struts community has probably inadvertently, under the leadership of its author and the author of a new family, conceded its future to other web MVC solutions (Spring, etc).
The core Struts people for some reason vehemently deny this in rude terms, but the truth is obvious. Struts probably is dead.
Dakota Jack
|
|
|
Message #154954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
The problem with ASP.Net is that it still holds to the page paradigm. And that it has no servlet equivalent. MSDN on Struts: "The Struts architecture is essentially derived from a combination of the Front Controller and Intercepting Filter patterns. The Struts framework provides a single controller that governs the application events, while filters catch and process incoming and outgoing events to ensure that each of the MVC components receive exactly the information they need."
MSDN on ASP.NET: "ASP.NET implements MVC using the Page Controller pattern. In contrast to the Struts implementation, which allows complete application-level control, the Page Controller pattern applies the controller at the level of individual pages. ... Very complex and large applications usually require more flexibility in page-to-page and page-to-process navigation. To provide this flexibility, the ASP.NET controller mechanism can be improved in two different ways: either by centralizing the Page Controller, or by implementing the Front Controller pattern on ASP.NET."
Afaik, ASP.NET 2.0 will have built-in support for Front Controller. Which Struts already have. Craig McClanahan ensures the public that Struts Classic won't die. At least while there are "volunteers who prefer to leverage their existing investment in Struts Classic."
Once I watched a documentary about Japan and their crafts. There was this one guy who was a carpenter. He went to another guy who made a proper plane for him. In order to make this plane, he went in the mountains looking for the perfect stone to sharpen the blade. He spent quite a while before he found it. Then he made a plane and gave it to the first guy, who then made a thinnest a smoothest slice. They used old proven tools and techniques and perfected their crafts to the max. Programmers usually do not do that ;)
Btw, anyone see Alan Holub's comments on Struts in this weeks SD Times? Pretty much my thoughts exactly. What exactly? Could you drop a link, please? Are you talking about this: "Pure OO systems are simultaneously more complex to build and easier to maintain than hybrid procedural/OO systems. ... Nonetheless, most Java shops don’t do anything like pure OO. In fact, many Java programmers don’t understand even the basic principles of OO design and programming. Moreover, many off-the-shelf tools encourage a procedural approach (Apache’s Struts open-source framework comes to mind). If you’re working this way, you won’t get most of the real benefits of OO, however."
It just depends on what to consider an object. Some prefer to think in page-oriented way, that page with underlying logic and data is an object. I prefer to consider only server data and code as part of an object. I regard a web page as a detachable faceplate on a cell phone.
|
|
|
Message #154956
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?
Using JSF's robust navigation capabilities, you can provide a redirect after post (there were 2 articles on theserverside.com on the topic). I know that JSF and Shale will probably come up with solution on inheritently protecting actions from double posts (as Struts had with tokens).
|
|
|
Message #154958
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Curse of Emare: Struts in Exile
Dakota Micheal McGrady Jack wrote:
The core Struts people for some reason vehemently deny this in rude terms, but the truth is obvious. Struts probably is dead.Dakota Jack
Oh yeah.
They even came up with a cover plan:
http://struts.apache.org/milestones.html
to show what happens in Struts core, past yet unreleased 1.3. ;-)
Very elaborate.
Then... there are all the CVS commits into Struts on the dev list. That won't fool anyone. ;-)
Only people on another level, can see this trough the tricks ;-) I bet all the people that say they use Struts are just the same guy, ha.
(up the medication intake please)
.V
|
|
|
Message #154969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue... It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?
I like that. Introducing Shale, Craig describes a (seemingly standard) approach for Struts 1.x programming, where "the setup logic and processing logic end up in two different Actions". I would appreciate a link to a page somewhere on Apache website which promotes this techique. I had to reinvent this wheel myself with the help of other resources including Ted Husted's tips.
Brian, browsers dislpay this retry/cancel dialog if a resource was loaded using POST request. For the browser, resource is the result page which you want to refresh, and the POST is the standard request type to submit a page. You can change requst type from POST to GET in the <form type="..." < attribute. This way browser will silently resubmit the form, and you would have to fight with resubmitted data. The choice which seems better to me, is to use redirection to the result page, which will be loaded using a separate GET. This way a browser won't display dialog because it simply loads a result page, not submits form data and receives a result page.
JSF allows to load result page using redirect, and what is the best thing, you do not have to do anything. The intermediate data is stored on the server for you in between requests. This works seamlessly, I tried it recently, you just need to add a <redirect> element to the config file. You can achieve the same effect in Struts Classic, but with some additional effort.
|
|
|
Message #154971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Duh! <form method="..." > attribute, of course.
|
|
|
Message #155179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
things were better before
Too much of one up manship in Java world.These frameworks
are all the rage these days but think about a poor new programmer who
has to learn1. Java2. http3. html4. strut5. JSF6. etc etcadded to that
new releases of api's and all this in the name of making things
easier. You must be dreaming. I think things were better when we wrote
our own simple frameworks using the core API. Struts is not that clever
after all.
I don't think it's oneupsmanship really, but it sometimes smells like
it. Like any other human endeavor that takes time to evolve, we stand
on the shoulders of what came before.
You do bring up a good point regarding the profusion of IT ideas, which
of course is nothing new. The increasing rapidity with which the ideas
profuse brings up a meta question: how do people keep up? I suspect
each individual's answer to this question is a closely kept personal
trade secret, but I thought I'd ask anyway.
I have my hands full just trying to develop JSF 1.2, but the
ideas keep coming. My process is just to block out time once or twice a
week and hit TSS, Java.net, and Slashdot. Go into just enough depth to
get the gist, and move on. However, even with that light treatment,
things are getting hard to handle.
Ed
|
|
|
Message #155181
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apache announces new sub-project of Struts: Shale
Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?
We're addressing this problem in JSF 1.2
Ed
|
|
|
Message #155246
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Quite an interesting read
Too much of one up manship in Java world.These frameworks are all the rage these days but think about a poor new programmer who has to learn
1. Java
2. http
3. html
4. strut
5. JSF
6. etc etc
added to that new releases of api's and all this in the name of making things easier. You must be dreaming. I think things were better when we wrote our own simple frameworks using the core API. Struts is not that clever after all. If you think that things are peachy in ASP.NET land, read this: Front Controller pattern for ASP.NET. The one that works, please!
|
|
|
Message #155271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Forms, transactions, tokens, redirects, and stateless view.
Using JSF's robust navigation capabilities, you can provide a redirect after post (there were 2 articles on theserverside.com on the topic). I know that JSF and Shale will probably come up with solution on inheritently protecting actions from double posts (as Struts had with tokens).
The documentation being slim, my naive impression of Struts tokens is that transactions aren't declarative. Surely JSF fixes that?
As for stateless view being a best practice, redirects seem easily configured in both Struts and JSF. But at the cost of worst possible latency and throughput. Maybe there's a better, more WAN friendly way of making the view stateless? Or is redirection essential, for more than just updating the browser's address bar?
Speaking of updating the address bar, I'd prefer not to do it during the pages of a token transaction, since browser bookmarking into the middle of a transaction's page sequence would be silly. During navigation along the page sequence of a transaction, it might be nice if there were no redirection and the address bar never changed. Hopefully JSF can round-trip a CGI form without altering the address bar?
A browser should seldom be given a page who's URL won't work if bookmarked or emailed. Redirected stateless view is a big step toward reusable URLs. But I think not redirecting during a transaction is also needed to have all reusable URLs. So maybe redirection isn't the best way to make a stateless view?
|
|
|
Message #155336
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Forms, transactions, tokens, redirects, and stateless view.
Maybe there's a better, more WAN friendly way of making the view stateless?
Nothing is more WAN friendly than stateFULL Swing client deployed with JavaWebStart :)
|
|
|
Message #155354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Forms, transactions, tokens, redirects, and stateless view.
As for stateless view being a best practice, redirects seem easily configured in both Struts and JSF. But at the cost of worst possible latency and throughput. Assembly language program is faster than Java. So what? This fraction of second that you care about will save you on page refresh and will provide robust and pleasant user experience. Isn't the whole thing about a user after all?Maybe there's a better, more WAN friendly way of making the view stateless? Or is redirection essential, for more than just updating the browser's address bar? Address bar is just the icing in the solution of a bigger problem.Speaking of updating the address bar, I'd prefer not to do it during the pages of a token transaction, since browser bookmarking into the middle of a transaction's page sequence would be silly. Why? You have views which show an object or part of an object using object ID. If you bookmark the URL, you will remember the "show product with ID..." view. If later a user would navigate to this URL, then if product is available it will be shown, if product was discarded during initial entry or removed, the user will see a "Product not found" error. Absolutely legit for me. Can you provide an example which does not work with this approach?During navigation along the page sequence of a transaction, it might be nice if there were no redirection and the address bar never changed. Hopefully JSF can round-trip a CGI form without altering the address bar? Browser simply displays the address of a resource received in response. What are you talking about is showing result without redirect. You already have that ;) The point is, that if you want to refresh the result, you need to tell server where to get it from. The only address that is available is the one in the address bar, which is logically is not the address of the resource you want to see, it is the address of the module processing the input! Here comes the POSTDATA dialog.A browser should seldom be given a page who's URL won't work if bookmarked or emailed. Redirected stateless view is a big step toward reusable URLs. Right.But I think not redirecting during a transaction is also needed to have all reusable URLs. Did not get that.So maybe redirection isn't the best way to make a stateless view? If we are talking about a pure and simple view, which only displays the information, then redirection is the only way. Without it you send your input data again to the server and you process it again, and you fight with double submits, and you use some weird things like tokens. This is not a view, this is the whole input/processing/output sequence done again. And do not forget users cursing you for clicking "OK" on POSTDATA dialog each time they navigate back and forth. Here is your latency and loss of throughput and loss of credibility. Redirection: lose a little, gain more ;)
|
|
|
Message #155428
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does the address bar have to track every click?
Address bar is just the icing in the solution of a bigger problem.
Today's most popular post on JavaBlogs is Dion's "XmlHttpRequest and company enable componentization". He suggests an alternative way of compositional page tiling by using DHTML for client side dynamic inclusion.
He describes its appeal: "Now, with XHR, each component can talk back to the server if it needs too, and the rest of the page stays put."
Is JSF ready for these HTTP requests that don't update the browser address bar?
I'm glad Dion saw the relevance to portals. It's unclear to me why the Java Portlet Specification chose server side inclusion instead of HTML frames? Is XmlHttpRequest the best portlet mechanism? Can JSF or Struts work with client side inclusion (XmlHttpRequest or frames)? I see that XmlHttpRequest is supported by IE, Mozilla, and Safari. That's universal reach. But XmlHttpRequest is just for practice until DOM Level 3 Load-and-Save is implemented.
Does the address bar have to show every CGI request? Wouldn't avoiding whole-page replacements make DHTML feel more like Swing? Fewer page URLs shown surely means safer bookmarks. During a token transaction, URLs could be hidden entirely, so avoiding the danger of bookmarking into a transaction.
|
|
|
Message #155483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE:Quite an interesting read
No, I'm not a Microsoft developer, i am J2EE dev. but i think things are getting out of hand now. One of the reasons i was drawn to Java was that it seemed like a good core api and a good language. but what is going on now? Open source overdose. It's a shame that Sun didn't sell java then they would have some money to develop it properly instead of creating comittees that are 5 years behind everyone else.
|
|
|
Message #157575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It would be nice ...
We're addressing this problem in JSF 1.2Ed
It would be nice to stop processing the double submit and reload the latest page. :)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
