6 Replies Latest reply on Apr 7, 2004 8:29 AM by jae

    MVC for Nukes

    Sherman Wood Apprentice


      The current approach of putting all operation code in the module classes does not scale very well - BBModule is up to 256K of source now. Some of that can be fixed by refactoring, but we are still left with the module class needing all the operation methods on it. As I am developing my application module, I am finding that I want to use the module as a controller, where each operation does some work (an action) and forwards to a view (template, JSP, whatever). JetSpeed 1.4 had this approach, which I found worked well.

      I spent a bit of time trying to get Struts in there, leveraging the JSP module approach by adding:

      <url-pattern>*.do</url-pattern>

      into the nukes-web.xml and trying to get the Struts packaging right, but I got lost. Any thoughts on how to do this? Is a StrutsModule only a little bit beyond JSPModule?

      Failing that, I am working on a ControllerModule class that will be driven off of a metadata file defining operation => action, view. I was originally thinking of this being a dynamic class driven by something like cglib, but AFAIK, that would require changes to how MBeans are created, so I will probably generate the code of a subclass of ControllerModule with a Velocity script from the metadata, with all the operation methods. Is anyone interested in this?


      Sherman


      PS. I look forward to the day where I can model a Struts app in UML, generate the code with AndroMDA (watch out for 3.0, coming out in the next month or so - way cool!) as a Nukes module, customize it and drop it in.

        • 1. Re: MVC for Nukes
          Viet Master

          This is the approach advocated by portlets too, in each portlet you have two methods :


          • action(ActionRequest req, ActionResponse resp)
          • render(RenderRequest req, RenderResponse resp)


            action(...) is first called and then render is called. this is where you can hook the controller and then let the render dispatch to the appropriate view.

            My idea is to extend the portlet interfaces to be able to convert nukes modules and blocks to that extended portlet.

            The spec defines well some points that are missing or not in the good shape into nukes today :


            • modules and blocks will fusion into the portlet
            • the difference knowledge/operational is defined by the fact that you deploy a portlet and then add portlet instances and then add portlet windows.
            • generic portlet preferences
            • URL management


              Nukes is a specialized portlet container that extends it. There are mainly two pluggable layers :


              • The user state layer : this manages the user state at different levels : window mode, portlet mode and portlet preferences
              • The instance layer : when you deploy a portlet that creates a Portlet object but it is not usable yet. This is where the instance layer plays a role. It is responsible to manage different instances.


                Then the portlet container use these two layers to invoke the existing portlets and produce a result. The result is then passed to the theme that creates the HTML result.

                So now, we don't want big changes in the current code. I still have some parts of the spec to implement. Then I will start to rebuild the infrastructure on top of that. I'll keep you informed of the changes, as soon as I have something I'll commit in the CVS. For those who wants to get a snapshot of my dev tree I can send it.

                I don't think it will be difficult to migrate the current modules to the new format.


          • 2. Re: MVC for Nukes
            Sherman Wood Apprentice


            I'd be interested to see where you are at.

            Julien, with the portlet piece being your focus now, should we tag a version 1.1 and get that out?


            Sherman

            • 3. Re: MVC for Nukes
              Viet Master

              I share the same idea, but it can wait a little. I want to fix bugs (the search bugs you cited and some others) in addition I am not ready to commit something right now.

              • 4. Re: MVC for Nukes
                jae Master

                is there anything pressing that needs to be addressed? i wouldn't mind a small "break" from the news module...

                and speaking of which, it is coming along nicely (slowly, but nicely) - i've pulled out about 60% of the html into templates and now i'm working on adding a small "framework" so we can support different types of news "formats" (fark style, slashdot style), one can only deal w/ html for so long. :)

                • 5. Re: MVC for Nukes
                  Viet Master

                  Jae, nothing is pressing but if you want you can pause and work on the JSP taglib implementation for the portlets.

                  • 6. Re: MVC for Nukes
                    jae Master

                    ooh - that sounds like fun. let me have a look at the spec later on today and i'll sync up w/ you after that.