Opinion: What do we need from a Controller?

Discussions

News: Opinion: What do we need from a Controller?

  1. Opinion: What do we need from a Controller? (25 messages)

    Over on the Apache Struts Development list server discussions have been going on about the proposals for Struts 2.0 (aka "Shale"), in concert with this we have Erwin Vervaet's Spring Web Flows recently announced. All of this has got me to thinking. What do we really need from a Controller? We have a lot of competing frameworks out there, each with a world view and enthusiastic user base, is this a race that needs to be won or has no-one defined the finish line yet?

    Read on: What Do We Really Need From A Controller?

    Threaded Messages (25)

  2. Continuations do seem to be the best fit approach to solving this problem. See:

    - RIFE
    - Cocoon Flowscript
    - The CodeHaus continuations project

    etc. I'll be interested to see what "Shale" does with the Dialog piece because that is meant to encapsulate an ongoing stateful conversation with the user.
  3. I'll be interested to see what "Shale" does with the Dialog piece because that is meant to encapsulate an ongoing stateful conversation with the user.
    It is very difficult to address a problem in a wrong place. IMO modal dialog should be part of standard JavaScript, simply put: making MS extension window.showModalDialog() standard would resolve many issues and make life way easier.
  4. Dialog Definition[ Go to top ]

    IMO modal dialog should be part of standard JavaScript
    The usage of Dialog in Shale terms refers to dialog as a conversation rather than a physical UI window. This is why I prefer sub-process as a name for this feature. So a Dialog may encompass several screens and the processing / routing between them, preserving local private state within the process/dialog.
  5. Dialog Definition[ Go to top ]

    IMO modal dialog should be part of standard JavaScript
    The usage of Dialog in Shale terms refers to dialog as a conversation rather than a physical UI window. This is why I prefer sub-process as a name for this feature. So a Dialog may encompass several screens and the processing / routing between them, preserving local private state within the process/dialog.

    That is easy to accomplish in Struts even now with session scoped action form that spans multiple actions.
  6. Dialog Definition[ Go to top ]

    That is easy to accomplish in Struts even now with session scoped action form that spans multiple actions.
    Is it? Think about it, consider how sub-processes might want to treat state as private, with nested processes saving values under the same logical key without stepping on each other and then have it all automatically cleaned up when each sub-process finishes. Sure you can implement exactly this using the Session scope and a bit of managment code, but it's not as simple as just "use the Session".
  7. Dialog Definition[ Go to top ]

    That is easy to accomplish in Struts even now with session scoped action form that spans multiple actions.
    Is it? Think about it, consider how sub-processes might want to treat state as private, with nested processes saving values under the same logical key without stepping on each other and then have it all automatically cleaned up when each sub-process finishes. Sure you can implement exactly this using the Session scope and a bit of managment code, but it's not as simple as just "use the Session".
    It is that simple.

    public abstract class AbstractAction extends Action{

    void storeActionValueIntoSession( String key, Object value, HttpSession session ){
        session.setAttribute( this.getClass().getName() + "-" + key, value );
    }

      Object getActionValueFromSession( String key, HttpSession session ){
        return session.getAttribute( this.getClass().getName() + "-" + key );
      }
  8. Dialog Definition[ Go to top ]

    Superficially yes, although that particular scheme falls down if two sub-processes use the same class. But I don't think it's useful here to debate implementation. The point is that this type of scoping is useful, and a Controller framework should provide it as a service, handling the implementation including persistence and importantly clean-up of state for you. Would you not agree?
  9. Dialog Definition[ Go to top ]

    Just thoughts:
    >> Be agnostic of the view technology. …
    Too much generalization hurts.

    >> Be driven by some sort of metadata…
    >> Make it declarative.

    Do not believe in that. Every program is a sort of workflow and it seems logical (from high vantage point) base every program on WF engine. That is not the case, in many cases it is much more convenient to handcode the WF as screens and dialogs, and implementation is much more transparent than obscure WF definition.

    >> Make security simple.
    Complexity of a solution should match complexity of the problem. Security is not simple.

    >> Escape the tyranny of the Servlet API scopes. In reality Application, Session and Request don't reflect the requirements of applications

    Those scopes for view only. Application logic should not care about them. So I would say there is nothing wrong about Servlet scopes.

    >> Back button support.
    Since everybody uses browser as application client, browsers should enable ‘application’ mode, i.e. no back/forward.

    Summary:
    The entire headache caused by using wrong technology ((x)html) for solving distributed client problem. We can infinitely discuss workarounds and fixes, but what we really need is to reevaluate entire technology stack and address problems in right places, rather than apply duck tape bandages.

    Resume: No, we do not need another SuperController.
    We have Tapestry.
  10. Dialog Definition[ Go to top ]

    Back button support. Since everybody uses browser as application client, browsers should enable ‘application’ mode, i.e. no back/forward. Summary:The entire headache caused by using wrong technology ((x)html) for solving distributed client problem.
    If the car technology was developing as fast as computer technology, we would have been driving fully automatic vehicles with nuclear powerplants by now. I don't know, is it good or bad that car industry is a little slower? On topic: it is possible to make HTML work. Another question, do we need to make it work or do we want to let it die while sleeping.
    duck tape bandages
    ;-)
  11. Dialog Definition[ Go to top ]

    On topic: it is possible to make HTML work. Another question, do we need to make it work or do we want to let it die while sleeping

    I do not advocate death of HTML, there are so-o-o many useful things browser can do. When we tried escape into Thin client, we immediately start reimplementing browser piece by piece. JavaDesktop does it right by providing cross platform wrapper for browser. However it solves only one problem: leveraging browser from Not-So-Fat-Client.
    IMO there is another class of application: they work of HTML just fine, but need real sleek automation here or there. This is where I see case for Applet-2 technology.
    Applet-2 should provide JavaWebStart managed (shared libraries, predictable caching, etc.) collection of related and communicating applets.
  12. I do not advocate death of HTML, there are so-o-o many useful things browser can do.
    Browser can browse hyperhext. The question is, should we leave to Caesar what is Caesar's, and to let God have what is God's? How much of functionality can browser have? Well, as long as it about presentation, everything will do, like style sheets, images, movies. How about client-based vector graphic renderer? XML parser? XSL processor? What else?

    But an application is not a hypertext which can be browsed back and forth, it is something different. Should we continue with our attempts of running thin application using technologies intended for hypertext, or should we move somewhere else? Macromedia is moving, and Microsoft too, and even Sun tries to resurrect the applets. I guess, this and the next year will become a turning point in web application technology. Especially considering that HTTP is dated by 1999. Freaking five years, man!

    Flash apps are not bad, if only they were faster and were running outside of the browser. The latter can be addressed easily, at least from the visual standpoint. The former... I don't know. If available demo Flash apps are not development betas, then Flash desktop technology is painfully slow. Which is strange, considering jumping and flickering Flash ads.
    IMO there is another class of application: they work of HTML just fine, but need real sleek automation here or there. This is where I see case for Applet-2 technology.
    Can you clarify what is "real sleek automation"? Application-guided wizards? No "Back" page? No flicker on page reload? Or something else?
  13. Especially considering that HTTP is dated by 1999. Freaking five years, man!
    Old does not mean bad. Pretty often quite opposite is true.
    I would say that IT has no clever new ideas. All smart ideas at least couple of decades old, or older.
    IMO there is another class of application: they work of HTML just fine, but need real sleek automation here or there. This is where I see case for Applet-2 technology.
    Can you clarify what is "real sleek automation"? Application-guided wizards? No "Back" page? No flicker on page reload? Or something else?
    I mean updating parts of page, standard and working trees, and other 'not-quite-standard' or custom page components.

    IMO extended Applets were just fine if we could guarantee Java on client, or somehow provide the same easy and fast uploading of JRE plugin (split monolitic rt.jar and native libraries and then enable JWS based lazy loading perharps).

    Flex might be fine, but there are no serious obstacles for Java to come back on Desktop because Flash+ActiveScript is just scaled down client Java: "wheel reinvention"...
  14. Why HTML?[ Go to top ]

    On topic: it is possible to make HTML work. Another question, do we need to make it work or do we want to let it die while sleeping
    I do not advocate death of HTML, there are so-o-o many useful things browser can do.

    It is absolutely correct that HTML is not for "aplication" (in the sense of this discussion thread.)

    We choose HTML as the user front end because (1) it has the most prevalent installation base; (2) it is cool for marketing people to be Web-based and so maybe they can sell more; or (3) you accidentally think you will have a lot more users than you can actually get.

    If the above issues do not apply to you, then you should probably just let people download an Windows EXE file and install it, and stay away from Java. ;-)
  15. Why HTML?[ Go to top ]

    On topic: it is possible to make HTML work. Another question, do we need to make it work or do we want to let it die while sleeping
    I do not advocate death of HTML, there are so-o-o many useful things browser can do.
    It is absolutely correct that HTML is not for "aplication" (in the sense of this discussion thread.)We choose HTML as the user front end because (1) it has the most prevalent installation base; (2) it is cool for marketing people to be Web-based and so maybe they can sell more; or (3) you accidentally think you will have a lot more users than you can actually get.If the above issues do not apply to you, then you should probably just let people download an Windows EXE file and install it, and stay away from Java. ;-)

    Unfortunately many customers in corporate environment impose a "no dependendencies in the client policy" which could be expressed better as "I have 500 clients connected in the LAN and i don't want to have the hassle to install your software, JAVA or .NET on all of them". WebStart with it's ability to detect changes and upgrade the software could be a solution, if it weren't for the fact that you have to install the JRE first.
  16. Why HTML?[ Go to top ]

    WebStart with it's ability to detect changes and upgrade the software could be a solution, if it weren't for the fact that you have to install the JRE first.
    And to see HTML we need a browser on client. We just have to have something on client reliably.
    People download and install browsers on their computers all the time, flash plugins, why the same could not happen to JRE?
    JavaWebStart sandbox seems like ideal solution for zero client administration and I do not quite understand why Sun/IBM do not promote it.
  17. Why HTML?[ Go to top ]

    WebStart with it's ability to detect changes and upgrade the software could be a solution, if it weren't for the fact that you have to install the JRE first.
    And to see HTML we need a browser on client. We just have to have something on client reliably. People download and install browsers on their computers all the time, flash plugins, why the same could not happen to JRE? JavaWebStart sandbox seems like ideal solution for zero client administration and I do not quite understand why Sun/IBM do not promote it.

    sounds like a good idea. the JRE is too bid to download-on-demand; the 1.4 JRE (not the JDK) on my PC is 42MB. most parts of it must be downloaded on demand but that's more difficult than it appears because the app may use some std API not being downloaded the first time. or the Java API should be shrunk incredibility. unfortunately it seems keep growing.

    it may work in LAN environment but then Windows EXE will do as well.
  18. Why HTML?[ Go to top ]

    the 1.4 JRE (not the JDK) on my PC is 42MB. most parts of it must be downloaded on demand but that's more difficult than it appears because the app may use some std API not being downloaded the first time. or the Java API should be shrunk incredibility. unfortunately it seems keep growing.it may work in LAN environment but then Windows EXE will do as well.

    The download for the 1.4.2_06 JRE for Windows is 14.96 MB. Of course, it may well expand on install...
  19. JRE size and JRE lazy loading.[ Go to top ]

    the 1.4 JRE (not the JDK) on my PC is 42MB. most parts of it must be downloaded on demand but that's more difficult than it appears because the app may use some std API not being downloaded the first time. or the Java API should be shrunk incredibility. unfortunately it seems keep growing.it may work in LAN environment but then Windows EXE will do as well.
    The download for the 1.4.2_06 JRE for Windows is 14.96 MB. Of course, it may well expand on install...
    My winXP laptop reports JRE size as 136 MB and SDK size as 426 MB in "Add or Remove program". Real disk size is 79 MB for SDK
    That seems strange to say the least...
  20. My winXP laptop reports JRE size as 136 MB and SDK size as 426 MB in "Add or Remove program". Real disk size is 79 MB for SDKThat seems strange to say the least...
    How does Add/Remove Programs get application size and other information
  21. Do you not mean rife.dev.java.net/
  22. Continuations and REST[ Go to top ]

    Continuations do seem to be the best fit approach to solving this problem.


    Continuations are an intriguing concept. I'm not sure if I agree with the fact that continuations are viewed as an alternative approach to designing web applications. In fact, I think "flow scripts" and the like, just become another way define and model a web finite state machine (albeit it does seem to be slightly more intuitive way of describing the flow of an application). I have seen continuations proposed as an alternative to FSM design. I simply don't think this is the case. As soon as there is a "break" in execution, you are at an application state, and once things "continue" you are in transition, so I see continuations in web apps as a way of defining State Machines.


    What may be lost though is the focus of resources and URIs. Given that, I wonder if continuations contradict Representation State Transfer network architecture. Do continuations promote the concepts of managing the states of network resources? With continuations will URIs remain "nouns"? And HTTP Commands as operations for the transfer and manipulation of resource states?


    Since continuation flow scripts can be seen as a way to model state transition - then it can be a REST-ful way to develop web applications. But if continuations are used to approach web design in a functional programatic paradigm, we will sacrifice best practice network architecture - hasn't that "made the web successful".
  23. Continuations and REST[ Go to top ]

    Your concern is a valid one. This is why in RIFE you are able to use continuations, but not required to. We advocate to structure your web application through the user of the data flow and logic flow declarations that are 100% REST-friendly since, by default, they maintain state on the client-side. Continuations come in play for 'islands of functionalities' that have not much use from REST accessibility for each step, but that gain a lot in development productivity when continuations are used. A typical example would be a multi-page form that needs all data to be filled in before being valid. There's not much use to be able to go straight to the 2nd step and being able to skip the first one. In fact, detecting such behaviour and handling it correctly is needlessly complex without continuations. The URL to start the multi-paged form action would the be REST compliant, and the rest an 'island of functionalities'.
  24. Continuations[ Go to top ]

    From cocoons continuation description:

    "With this approach clicking the Back button in the browser is no longer a hassle to deal with for you as a server-side programmer. They will simply refer to past continuations objects, which have their own state of the local variables."

    Gee, they found out about the session id. Not much different from, say the concept of a control tree in something like WebLogic Portal. However read carefully: Past continuation objects? Store all application state for all pages in the past (well, some safeguard must be there so that you can't go back sometimes), but while I always found cocoon nice in some ways and suboptimal in others, this looks very resource hungry to me for an actual, real world application.

    But if we do it using html proper let's do it all the way: What happens if you click "open link in new window"?? Frightening indeed!!
  25. Continuations[ Go to top ]

    I don't know the details of the Cocoon implementation, but in RIFE you can configure the preservation of each continuation. You get the most natural functionality by keeping them all since users are then able to go back to anywhere and follow different trails. Like you said, this is rather resource-hungry, so you have 2 options here.

    Either you're careful when developing with continuations and limit the size of the local variable scope by putting certain complex and well defined parts of logic in 'uninstrumented methods' that will not handle continuations.

    Either you configure the continuations to always invalidate the previous one. Even in this scenario, the user will not get very confused since the real application structure in a RIFE web application is defined in data flow and logic flow declarations, continuations are merely 'islands of functionalities' that should handle well defined, isolated tasks. So if someone presses back, and a non existing continuation is asked from the server, it will be as if they start the functionalities of the little island again. This will normally be an easy to understand situation (they're back at step 1 instead of step 3), and users shouldn't be too bewildered.
  26. Please go back on more step and debate wether a page flow oriented approach is sufficient at all.