Struts 2.x 'Shale' Proposal

Discussions

News: Struts 2.x 'Shale' Proposal

  1. Struts 2.x 'Shale' Proposal (28 messages)

    Many people have questioned how Struts and JavaServer Faces will fit together in the future. A detailed proposal for Struts 2.0 (code named Shale) is available, and shows that it will be based closely on the JavaServer Faces specification.

    Overview
    The briefest way to state the proposed architecture is to fulfill the following goal statement:

    Divide the responsibilities of the monolithic Struts 1.x controller into individual layers, whose features may be composed in appropriate combinations based on the requirements of a particular application.

    To that end, the following primary layers are proposed:

    • Application - Framework for performing processing that is required on every incoming request, plus a place to plug in application-wide services that are offered as standard plug-ins.
    • Dialog - Framework for managing a series of individual interactions with the same user, necessary to complete a particular business transaction, plus a mechanism for plugging in predefined dialog services that are offered as standard plug-ins.
    • View - Framework for elegantly combining a view tier technology that actually composes an individual HTTP response with the corresponding business logic interactions (to retrieve or modify data in the model tier), as well as handle user interface events activated by the user.

    Read more: Struts 2.x 'Shale' Proposal

    Threaded Messages (28)

  2. Struts 2.x 'Shale' Proposal[ Go to top ]

    First on JSF. I have not used JSF yet, but from what I've read I can say that I am not enthusiastic. If my points are not valid, please correct me. JSF builds rich application on HTML basis, but the page markup is not exactly HTML. So, in the same way as standard HTML processor cannot read JSP markup, it cannot read JSF as well, so I need a dedicated JSF authoring tools. Why would I want to use a "new" technology, if it is not better than JSP? Either drop HTML and use something like Flash, or keep HTML but clean it up from non-HTML elements. There are several tools/frameworks, which allow to tie clean HTML code to backing Java code. JSF in this sense is a "dirty" solution, no much better than JSP.

    JSF spec says, that "Faces Request Generates Faces Response" scenario is the most common in JSP. Does that mean, that normally POST requests receive meaningful responses? Can redirection to the View be implemented easily with JSF? How often will I see "POSTDATA will be resent" message?

    JSF spec also says, that in non-portlet environement it is possible to redirect to View: "use the <to-view-id> element of the matching case to construct a context-relative path that corresponds to that view
    id, cause the current response to perform an HTTP redirect to this path, and call responseComplete() on the FacesContext instance for the current request." I see that responseComplete() is called on this step, does this mean that redirected View cannot be a JSF View? And according to the same spec, portlets do not support redirection at all, bummer.

    Now on Shale, very short. At first glance it does not differ much from ASP.NET, which approach to webapps I do not like. I will read Shale proposal more thoroughly later, though.
  3. Struts 2.x 'Shale' Proposal[ Go to top ]

    Why would I want to use a "new" technology, if it is not better than JSP?

    JSF builds on JSP, but instead of using a request-response approach, where the HTTP protocol is very visible, JSF tries to hide the protocol to a much greater extent, and use an event driven approach instead. You can still use the same tools for JSF development, but the greatest promise of JSF is to replicate drag n' drop development ala delphi or VB.

    In reality, many of us need to delve down the protocol level in out applications, so I'm not convinced that this is the best solution. Then again, Sun are aiming this technology at corporate developers, the VB types who want to get visible results quickly and who are willing to work within the constraints of their IDE.
  4. Is it VB for the Web?[ Go to top ]

    JSF builds on JSP, but instead of using a request-response approach, where the HTTP protocol is very visible, JSF tries to hide the protocol to a much greater extent, and use an event driven approach instead. You can still use the same tools for JSF development, but the greatest promise of JSF is to replicate drag n' drop development ala delphi or VB.
    Don't get me wrong, I like Delphi. No, I love Delphi. I used it for about 5 years right from 1.02 till 5.0 and the product is great. Probably the best development tool for Windows ever, too bad that VB was released one year earlier and stole the thunder. But web development is slightly different thing. As you pointed out, HTTP is highly visible, and it affects the programming model and user experience A LOT. A framework should hide HTTP really well, if it wants to deliver smooth drag-and-drop, window-based development. ASP.NET tries to achieve this, and it works as long as you develop the webapp (and as long as the end users use it) according to ASP.NET programming model. But try to reach out of this Procrustes' Bed, and you would end up writing your own framework.

    ASP.NET has built-in support for Page Controller, but not for Front Controller, which "inferior" Struts, incidentally, has. ASP.NET and Shale have notion of postbacks. They have control objects, which back the HTML controls. They have events and messaging. They try to implement VB/Delphi on web. But who said that window-based model is good? It ties presentation and business logic. It ties input and output. This model is great for fast prototyping, but ultimately you would end up splitting your presentation, model, business rules and input. So, what's the point?

    I do not like to submit input to the same form, I do not like output rendering in response to POST, I am not extatic from the idea of "controls" for web, I just hate to pass state in request/response headers. I prefer cleaner MVC model, and while we are talking about Struts, it already allows to do that.

    For me, input is just data, nothing more. I have a domain model and business rules. My model receives input, I do not care where it comes from: from the window, from browser or from the web service. I process that input and generate the output according to client type and state. The strength of the Web is that a webapp can take input from anywhere, and can render anything, it delivers resources, not fossil window forms. I do not want to crawl back to the shell.

    On the other hand, this model can work quite nice on smaller desktop-like projects, if state is handled on the server, and response View is fully detached from originating POST request using redirection.
  5. Is it VB for the Web?[ Go to top ]

    Matt has just dicussed this topic on his blog, some disturbing news in there IMO.
  6. Is it VB for the Web?[ Go to top ]

    But who said that window-based model is good? It ties presentation and business logic. It ties input and output. This model is great for fast prototyping, but ultimately you would end up splitting your presentation, model, business rules and input. So, what's the point?
    The point is "easy-of-use", plain populism. Some MVC frameworks with window-based UI convert events to requests and commands and they do it for reason (GEF is a popular one), I can not understand how requests and commands are bad for web UI.
  7. Struts 2.x 'Shale' Proposal[ Go to top ]

    I am not sure I understand whats Shale. Is Struts2.0 going to complement JSF or will it be an alternative to JSF. If former, what benefits does a Struts2.0 + JSF app have over a JSF app.
  8. Shale, stratified[ Go to top ]

    As far as I understand, Struts 2.0 is supposed to have less monolythic structure with pluggable modules and with additional services; JSF is supposed to be the primary rendering mechanism, but they should not lock developers in it.

    I do not welcome the ASP.NET-induced drift to code-behind form-based approach, because I find this design unflexible. I like the clear separation between input, business process and output, which Struts already provides. Shale proposal notes: "In Struts 1.x, for example, the setup logic and processing logic end up in two different Actions, requiring multiple action mappings, and a tendency for people to implement action chaining and be surprised by the results. A more developer-friendly approach would be to combine the tightly coupled processing actions into a single Java class, implicitly associated in a 1:1 relationship by a (pluggable) mapper, so that the entire combination has a single "identity" from the point of view of the application framework." Do they really think this will bring blessing to J2EE soil?

    I was there and back, I made a circle and returned where I started, and now I believe that the approach which is employied in Struts 1.x is flexible enough and allows to build user-friendly web apps. The central object to ASP.NET which Shale tries to copy the View Controller from, is not the domain object, it is the window. Microsoft has its own agenda, it leverages its existing windowing technologies and practices, thus converting a VB developer into ASP.NET develper overnight. But J2EE does not have this legacy.

    Struts in its current form allows to separate input from output, dedicating one action mapping to input form data, and another to render the result page. Thus, standard "Insert and Display" operation for a CRUD application can be split into "Create" and "Display Created". Now make another step and convert "Display Created" into generic "Display" and you get fully modular architecture, which does not really care where input came from. This stimulates code reuse and forces to use clean object-based design, where every data item belongs to a particular object, and every object has an ID. Another benefit that "Display" action can return almost anything, from plain text to fancy multimedia page to web service XML response.

    When I was a kid, I used to do a lot of things, and when asked why did I do it, I would answer: "Because other guys did the same". My grandma used to ask: "If others would jump out the window, would you join them?"
  9. Shale, stratified[ Go to top ]

    I have to agree with you on the points of properly layering your application.

    I've said it before, the bonus of JSF and the application framework it presents is that it allows the developer to scale/layer on their own.

    Example, I could have JSF generate a POJO Login object on the request and have a method on it that checks against the database, or pass the object right to the business layer. On the other hand, I could have JSF pass a POJO login bean that delegates all of its behavior to the business layer. Again, the point is that it's up to the developer.

    I don't like Struts at all. It forces the developer to create layers that might be unecessary and I would say even forces your code to be nearly untestable outside of a serlvet environment.

    Since JSF is protocol generic and all of the business code you write doesn't depend on the JSF framework itself, you can easily test what you write. I'm on the JSF-RI development team and all of the code I wrote was all tested through JUnit, some Cactus, and even a few Main methods. That's the beauty of JSF.
  10. Shale, stratified[ Go to top ]

    I don't like Struts at all. It forces the developer to create layers that might be unecessary and I would say even forces your code to be nearly untestable outside of a serlvet environment.
    I wouldn't say I don't like it at all, as no other framework is as mature as it is (the documentation is not that good, but you can find a lot of help and articles on the internet). But after having used it, I came to the exact same conclusion. When I talk about it to other developers that don't know a lot about it, I just say "it is too heavy" (what you said is what I mean by this). Those other developers then look at me strangely, because I'm probably the only developer they know who criticize it. I'm glad I've found someone that came to the same conclusion. :-)
  11. Page-oriented programming[ Go to top ]

    If Shale ViewController will bring us page-oriented development, unlike current Struts, that would be great.
  12. What I'd like for Struts out of the box to provide is:

    1) a refined DispatchAction that wraps request etc. in an ActionEvent, like
    public String doSave(ActionEvent evt) throws Exception{
        MyBean b = (MyBean) evt.getForm(); //evt.getReq(); etc.
        b.save(); //or whatever
        return "Success"; //forwardname
    }
    that I can call with
    <html:submit property="method" value="save"/>
    or
    <html:hidden property="method" value="save"/>
    or similarly /do/myAct?method=edit&ID=50

    Makes for very clean code, and "page-oriented programming". Vic, you did an implementation for this available under Apache license, we have the code, could it be contributed to Apache Struts (whatever is next version)?

    2) auto discovery of struts config files as in
    <servlet-name>action</servlet-name>
    ...
    <param-value>/WEB-INF/*/struts-config.xml</param-value>
    finds all struts-configs under /WEB-INF
    ; same for tiles layout.xml, validation.xml

    3) tiles definitions mapping to a virtual url
    <definition name="home.pg" url="/en/index.jsp" template=...
    where /en/index.jsp doesn't need to exist but is the stable url.

    Best,

    Wolfgang Gehner
    http://www.infonoia.com
  13. Vic, you did an implementation for this available under Apache license, we have the code, could it be contributed to Apache Struts (whatever is next version)?2)

    I belive Ted Husted saw how this is implemented. When you upload code to sf.net, post a message on Struts lists and see if they like it.

    There are 2 things going on at Struts now, one is evolutionary (chain) the other is revolutionary experiment (Shale). And... I have a proposal of my own on an MVC framework for SoA that I will likely release in months.
    .V
  14. Struts 2.x 'Shale' Proposal[ Go to top ]

    Time to move on to WebWork :-))
  15. Echo Framework[ Go to top ]

    I dont`t want to deal with http, javascript, css, html, tag-libraries, beans, etc. anymore. So i use the echo framework and 100% pure java.
  16. Navigation[ Go to top ]

    I dont`t want to deal with http, javascript, css, html, tag-libraries, beans, etc. anymore. So i use the echo framework and 100% pure java.
    Echo's nice but the browser back button 'don't' work (at least not with the demo I saw). Basics for a webapp.
  17. Navigation[ Go to top ]

    Echo's nice but the browser back button 'don't' work (at least not with the demo I saw). Basics for a webapp.

    Well that said the Back Button works with almost no HTTP based approach ootb, because (among other things) the model has been changed during pressing submit and back does not (a) represent the state of the model or (b) fails to render because the model has been changed, the form bean is gone etc. etc. .

    In about 95% of apps I have seen, the back button does not work (and does not integrate with "pressing submit again"). Using things like redirection patterns etc. should be common place by now, but they usually involve some time for thought (tm) that you are more often than not not granted...
  18. Navigation[ Go to top ]

    I dont`t want to deal with http, javascript, css, html, tag-libraries, beans, etc. anymore. So i use the echo framework and 100% pure java.
    Echo's nice but the browser back button 'don't' work (at least not with the demo I saw). Basics for a webapp.

    When developing business apps with a web-frontend I usually open the application in a chromeless window (bar the title) and disable or substitute the context menu to avoid issues with navigation. At the end of the day these kind of apps are not web sites.
  19. Browser Back Button[ Go to top ]

    I always include a javascript link/button in my login pages, which opens a browser window in fullscreen-mode after successful login. A very easy solution to avoid navigation with browser buttons.
  20. Browser Back Button[ Go to top ]

    I always include a javascript link/button in my login pages, which opens a browser window in fullscreen-mode after successful login. A very easy solution to avoid navigation with browser buttons.

    And what happens when user like me clicks on left mouse button + right mouse button for back?

    I think nowadays most users are accustomed to the web application UI "code of conduct" anyway, and will just be confused / annoyed if their web application changes the normal environment by removing some browser buttons.
  21. Navigation[ Go to top ]

    I dont`t want to deal with http, javascript, css, html, tag-libraries, beans, etc. anymore. So i use the echo framework and 100% pure java.
    Echo's nice but the browser back button 'don't' work (at least not with the demo I saw). Basics for a webapp.
    Basics for the hypertext. HTTP is about linked documents, not about web applications. HTTP is outdated, it should be enhanced long ago to specify different behavior for web applications and for hyperdocuments.
  22. Navigation[ Go to top ]

    I dont`t want to deal with http, javascript, css, html, tag-libraries, beans, etc. anymore. So i use the echo framework and 100% pure java.
    Echo's nice but the browser back button 'don't' work (at least not with the demo I saw). Basics for a webapp.
    Basics for the hypertext. HTTP is about linked documents, not about web applications. HTTP is outdated, it should be enhanced long ago to specify different behavior for web applications and for hyperdocuments.

    Many will agree including myself, but we have to deal with the tools/environment now available (and mainstream).
  23. Shale is a new hope[ Go to top ]

    I'm very excited about the Shale proposol, even though up to now i don't understand all details.

    This is the first time that i saw someone clearly separating the layers
    A) Application
    B) Dialog
    C) View
    including a no-nonsense description why and how this layers are different.

    In 99% of all Java Web-Frameworks, either A)+C) dominates (Struts, JSF, ...) or A)+B) is in the focus (WingS, a lot of in-house frameworks).


    Most peaple don't even know that B) is not C), and the discussion above somehow reflects this ;-)

    The introduction of a Dialog has IMHO nothing to do with the PageController ("ASP.NET way of live") vs. FrontController ("Java/Struts/... way of live") discussion, that is a different story alltogether.


    I've seen a lot of in-house frameworks that have a strong Dialog focus, mostly build around a finite state machines to model the dialog flow and a hidden flag for the dialog name and a dialog instance counter.

    One thing i've never seen is a smooth integration of the different navigation requirements of the view-centric and the dialog-centric aspects of a web application.

    I would expect that stuff like double submit detect, back button handling, multiple independent instances of a dialog, ... are all handled in a A/B/C framework, but i have no idea how to achive this, and if Shale can deliver that right now.

    Shale is still in its infancy, and perhaps will take a long for a polished product, but for me, they did a great first step to differentiate between A/B/C.

    Bye,

    Jürgen
  24. The Dialog's the thing...[ Go to top ]

    One of the most important features of Shale that no-one has commented on yet is the concept of a dialog or sub-process, with it's own state management. I feel this is a key feature, certainly if any re-use model is important to you.
  25. A great proposal[ Go to top ]

    I liked what I read. I really did.

    I always had the feeling of hating Struts way of doing stuff (ActionForms, Dyna action forms, etc).

    But This 'Shale' thing is really promising.
    While the whole proposal introduces good things, here are some points that got my attention:

    1- The Dialog Framework: nice addition that would save a lot of common efforts. Continuations support -if done right- would be amazing, I enjoyed it in Cocoon for a long time.

    2- JSF: Java Server Faces lacks the true Controller part; 'Shale' would solve that elegantly.

    3- Service Provisioning: The idea of including Spring -or some other equally kernel- is great. Having Spring support inside 'Shale' would be a good choice.

    Shale Proposal is a great step in the right direction for Struts IMO.
  26. By the way, Shale proposal contains interesting phrase: "In Struts 1.x, for example, the setup logic and processing logic end up in two different Actions, requiring multiple action mappings, and a tendency for people to implement action chaining and be surprised by the results." Well, I am doing all of it, and yes, I was surprised by results when I tried to use form beans with different scope. I got to this action splitting idea myself, apache web site did not advertise it as a standard practice.

    So now I am getting curious: can someone show me a link to Struts good practices or such, where this technique is described? I am getting tired of inventing the wheel.
  27. Struts 2.x 'Shale' Proposal[ Go to top ]

    Work with JSF, Struts and/or new Shale ?

    With Shale is end of JSF ?

    Thanks.
  28. Struts 2.x 'Shale' Proposal[ Go to top ]

    Work with JSF, Struts and/or new Shale ?With Shale is end of JSF ?Thanks.

    Shale is certainly not the end of JSF - Shale includes JSF
  29. Struts 2.x 'Shale' Proposal[ Go to top ]

    JSF... and everything else besides

    From a first look, unfortunately Shale seems to suffer from Struts affliction, of trying to be too many things at once. Is it a wizard-navigation framework, or an AJAX framework, or a Spring integration framework, a validation framework, etc.?
    It bothers me that if I want to utilise (or read through the source for) just one portion of a framework such as this, I'm left having to sift through which are the _relevant_ jar or JRE dependencies, when integrating with my existing apps/appserver.