New MVC framework for web based J2EE apps: WebCtl

Discussions

News: New MVC framework for web based J2EE apps: WebCtl

  1. WebCtl is a very simple framework for building web based J2EE applications. It features a Central Servlet that dispatcher, execution of Command pattern-style objects within an EJB contex, support of asynchronous processing via JMS and Message Driven Beans.

    Check it out at http://pages.infinit.net/bansi/webctl.

    More info:
    -----------------
    WebCtl is a framework for building web based J2EE applications.
    This framework has been build with one goal in mind: SIMPLICITY
    - WebCtl is for EVERY body. Don't need to be a J2EE guru. No need to use Entity, Session beans etc. Just use standard JavaBeans ( for business logic ) and Java Server Pages ( for user interface ).
    - The API is tiny ( ~30K ): No need to learn tons of classes.
    - Simple architechture based on well known design patterns like: Model-View-Controller, Command, Publish-Subscribe

    FEATURES
    - Central Servlet that dispatch user request to Command objects
    - Execution of Command object within EJB context
    - Support of asynchronous processing via JMS and Message Driven Beans
  2. This is different from a million other small footprint based MVC servlet frameworks exactly how?

    My favourite small footprint MVC is Rickard Oberg's WebWork, very clever ideas, simple in it!
  3. How about Struts?
  4. well I think the extra features that webCtl has is the notification machanism that is the "channel and listner" of webCtl's own description.

    I like this feature.It could same some response time in some cases.


  5. Interesting, but it's both too simplistic and not *that* easy to use.

    For example, the WebCtl sample code would be implemented in WebWork like this:
    public class RegisterCommand
       extends ActionSupport
    {
        private String m_name;
        private String m_email;
        private String m_address;
        private String[] m_subjects;

       public void setName( String name ) { m_name = name; }
       public void setEmail( String email ) { m_email = email; }
       public void setAddress( String address ) { m_address = address; }
       public void setSubjects( String[] subjects ) { m_subjects = subjects; }

        protected void doValidate()
        {
           if ( m_name == null || m_name.length() == 0 )
               addError( "name", "Name is required" );
           if ( m_email == null || m_email.length() == 0 )
               addError( "email", "Email is required" );
        }

        protected String doExecute()
            throws Exception
        {
           // Do registration
           // Send message to listeners here
           return Action.SUCCESS;
        }
    }
    --

    Way way shorter, and less intrusion of the framework (no custom exceptions, no custom "result" notions (the SUCCESS
    constant is the "success" string). You will also notice that sooner or later you will have need for more things than are possible with the basic API, and then it will grow too. We had the same small API in WebWork in the beginning, but it has grown larger as needs has arisen. They key is to make the basic necessary API small and *how to use that API small* (which WebCtl fails to accomplish).

    Sorry, but you'll have to do better than this if you wanna fight on the framework scene ;-)

    /Rickard, completely unbiased lead dev of WebWork


  6. What is the link to download and examine the code of WebWorks and write some test applications with it? You reference a framework, but provide no direction to accessing it? This is not the commercial product at the site webworks.com? If so I have not found a way to download the framework to look at it, like I just did with WebCtl.

    Thanks,
    Bob
  7. No need to answer my question. WebWork can be found at:

    http://sourceforge.net/projects/webwork/

    Bob
  8. Interesting, but it's both too simplistic and not *that* >easy to use.


    Simplistic, I dont think so. Simple, yes.
    What's that difficult to use in WebCtl?
     - Command are simple JavaBean objects.
     - 1 function to implement: CommandResult cmdExecute() (instead of doValidate() and doExecute()).
    The contract between the WebControllerServlet and Command is simple: The WebControllerServlet executes the Command, not to validate it. It's the responsibility of the Command to validate itself before executing the task. Isn't it simple enough?

    >Way way shorter, and less intrusion of the framework (no >custom exceptions, no custom "result" notions (the SUCCESS
    >constant is the "success" string).

    - In WebCtl, there are more stuff that is needed after the execution of a command:
       1. a result code. That is used for the page navigation ( SUCCESS brings to sucess.jsp, FAIL brings to error.jsp )
       2. a Map of values to send to the next View
       3. a Map of data to send to the CommandListeners
    Don't you think that [2,3] are valuable?


    >You will also notice that sooner or later you will have >need for more things than are possible with the basic API, >and then it will grow too. We had the same small API in >WebWork in the beginning, but it has grown larger as needs >has arisen.

    I aggree with you, there are some services that will be needed soon (logging, security etc), but those will be added without breaking the WebController-Command contract. That can be more easyly because CommandResult object can be expanded without breakink the Command interface (or adding more interfaces).

    >They key is to make the basic necessary API small
    WebCtl isn't it small enough for you ???

    >and *how to use that API small* (which WebCtl fails to accomplish).
    May be all we need are more samples so that you can understand how to use it.


  9. Simplistic, I dont think so. Simple, yes.

    > What's that difficult to use in WebCtl?
    > - Command are simple JavaBean objects.

    As in WebWork (and many other frameworks).

    > - 1 function to implement: CommandResult cmdExecute()
    > (instead of doValidate() and doExecute()).

    Actually, WebWork only *mandate* execute() (which is in the Action interface), but since it's so common to have validation code the ActionSupport base class allows for splitting up code in doValidate() and doExecute() in order to make them more reusable (for example you could subclass an action and only change the validation logic; how do you do that with WebCtl? Answer: by doing it the same way WebWork does).

    > The contract between the WebControllerServlet and Command > is simple: The WebControllerServlet executes the Command, > not to validate it. It's the responsibility of the
    > Command to validate itself before executing the task.
    > Isn't it simple enough?

    The Command should indeed validate itself, but it is good to separate execution of the command from validation of the input parameters (internally in the command, as described above) to make the Command itself reusable.

    > - In WebCtl, there are more stuff that is needed after
    > the execution of a command:
    > 1. a result code. That is used for the page navigation
    >( SUCCESS brings to sucess.jsp, FAIL brings to error.jsp )

    WebWork does this too, but simply by having execute() (or doExecute() if you use the base class) return a string. No need for a custom "result holder".

    > 2. a Map of values to send to the next View

    In WebWork these are the get-methods of the action/command. Much more JavaBeanish to do it that way. How JavaBean-ish is it to return a Map that you can get values from? Not at all!

    > 3. a Map of data to send to the CommandListeners

    Why should the controller servlet have to deal with this?

    > Don't you think that [2,3] are valuable?

    I think that 2) is useful and done simpler in WebWork, and I think 3) is useful but should be a command internal thing. If you use the base class pattern (and sooner or later you'll introduce this, I guarantee you) then that base class can deal with it much better.

    > I aggree with you, there are some services that will be
    > needed soon (logging, security etc), but those will be
    > added without breaking the WebController-Command
    > contract. That can be more easyly because CommandResult
    > object can be expanded without breakink the Command
    > interface (or adding more interfaces).

    How would expanding CommandResult help in this expansion?

    I'm mostly talking about the Command getting more information to use in the processing, such as getting access to the session object and application context settings. How do you intend to accomplish that?

    > >They key is to make the basic necessary API small
    > WebCtl isn't it small enough for you ???

    Yes, too small. That's why I said it was simplistic.

    > May be all we need are more samples so that you can
    > understand how to use it.

    Absolutely! Can you provide a sample of a basic web shop, with carts and i18n and wizard handling? That will provide a lot of different useful things, such as session access, locale choosing, and stateful process management.

    /Rickard
  10. And how about this?

    public class RegisterCommand extends RecordPage
    {
      private String name;
      private String email;
      private String address;
      private String[] subjects;

      public void setName(String value) { name = value; }
      public void setEmail(String value) { email = value; }
      public void setAddress(String value) { address = value; }
      public void setSubjects(String[] values) { subjects = values; }

      public void doExecute() throws PageBeanException
      {
         // Do registration
         // Navigate to next page
      }

      protected String getSubmitCondition()
      {
        return "name and email";
      }
    }

    This is how I would do it in my framework (currently in development, not yet in SourceForge). RecordPage is a
    support class that extends from the base PageBean class,
    and provides a model for simple record-editing pages.
    The submit condition is evaluated upon form submit, but the
    really cool part is that the tags in the JSP page generate
    all the DHTML code necessary to control the status of the
    submit button (and it accepts arbitrarily complex boolean expressions on the page fields).

      - Rogerio