Objective HTML - An alternative to the MVC

Discussions

News: Objective HTML - An alternative to the MVC

  1. Objective HTML - An alternative to the MVC (19 messages)

    For those who have experienced the tedious and cumbersome process required to implement MVC try this alternative. The toolkit is aims at making html form development similar to the code you write for something like Java-Swing.

    Some advantages of Objective HTML are:
    - Form data is much easily handled and much more intuitive
    - No need to have 3 pieces of code like MVC (jsp, bean, controller), instead most of your code lies in one file
    - Less knowledge of html required, most of the messy html code is abstracted in the Java objects
    - Much more Object-Orientated for the discipline freaks

    Check out the Objective HTML homepage.

    Threaded Messages (19)

  2. I would not say it is replacing the MVC model. It is a different implementation of it. The controller is the JSP page (which is in fact compiled into a servlet at run-time), the view is implemented in "self-renderable" widget classes and the model has to be implemented separetely and can be called from the custom specialisation of the "Form" class.
    The model will allow faster implementation for most of the basic html forms, but takes away some control over the look & feel. I have seen some commercial implementations as well, but were too heavy-weight to try them out...
    It is a good start and there is plenty of room for extension and improvements. For example, this could allow "real" objects to control their representation by deciding when they are rendered in an HTML context or in a fat-client and decide if they use HTML rendering or Swing/AWT/SWT/XML...
  3. In the example the JSP page was the controller, but thats not to say you have to implement it this way. You can do what you would normally do, i.e. have a Main.jsp that calls
    URLProcessor class that farms off the request. This could then call your HtmlForm object and when it eventually gets forward to the JSP page, the JSP page could just call printHtml.
    You definitely have more flexibility with your traditional JSP, but with JSP your html code is also prone to becoming very messy. Its possible to make it neat and tidy, but it doesn't happen often.
  4. Nice idea about the fat-client. I'm going to look into having the objects be able to write out XHTML as well as standard HTML. I don't know much about XHTML other than from a high-level but I will look into it.
  5. Objective HTML - An alternative to the MVC[ Go to top ]

    More of an alternative to HTML, actually.
  6. Objective HTML - An alternative to the MVC[ Go to top ]

    Point taken. I guess what I mean to say is that its an alternative to the MVC solution provided by the Sun Blueprints. I will update the documentation with a more appropriate description for the toolkit.
  7. It seems to me that this is the wrong approach.

    For us technical guys, it seems attractive : no need to know HTML to produce HTML pages and forms. Use Java instead.

    But in the real world, the persons who write Java code aren't the same as the ones who write HTML pages. Ideally, a web designer should be able to load a JSP page in his favorite HTML editor (FrontPage, etc.), and see the page in WYSIWYG without too many problems, in order to modify or customize it. That's one of the resons why custom tags are better than scriptlets.
    Struts also has this problem with its custom tags : it transfroms a HTML page into a whole bunch of custom tags where the forms are not visible anymore.

    Just my two eurocents.

    JB.
  8. Well I don't know what 'real world' you come from but I've been on projects where I've written the html code and java code behind it and I know other people who do that to. This seems to be more and more the case now, people get hired who knows the html and the java code. If all you know is html, then good luck in finding a job in these times.

    If you where building a Swing application or VB application would you go, hey I can't build the user-interface someone else does that!? I don't see a real difference in building html forms. Html web pages are meant to be pretty, but how pretty can you make the form itself? The reality is that business logic drives the user-interface, so I think its wrong to decouple them completely like how you will if you use the standard jsp, bean, controller approach.
  9. Objective HTML - An alternative to the MVC[ Go to top ]

    However, on larger projects it is likely that you will have a team dedicated to the 'front-end presentation layers and a team dedicated to the 'back-end' business layer. At least, several of the companies I have worked at have organised things that way to great effect. However, this is on large projects with teams of 6-12 memeber.

    One common model I have witnessed is to have 'Interface Engineers' handling all of the presentation layer, including HTML, JSP, some graphics manipulation (nothing too serious just splicing the interface designs into gifs), client-side validation and the like. 'Application Engineers' handle the EJB and data tiers and any relevant framework code and servlet plumbing.

    With effective organisation, the Application Engineers can document APIs that the Interface team can utilise.

    Especially in situations where we are developing browser clients richer than plain HTML, with complex JavaScript, it is imporant to have specialists...also, this division is a realistic break down of common skills in the market place...you just have to peruse the forums on The ServerSide to witness the many programmers struggling with the most rudimentary HTML that any decent front-end specialist knows backwards and forwards and in version 3 browsers and in Netscape 4 for Mac.

    Part of the reason we go with such monlithic architectural patterns is to allow this type of seperation.

    <rant>
    Also, as an aside, one of the reasons that software remains so incredibly bad and user-UNfriendly is that we insist that 'The reality is that business logic drives the user-interface'...the interface should drive the business logic. This is an incredibly difficult concept for programmers to accept, but it is absolutely true. Most software that is written is designed to be USED, not by mythical USERS but by PEOPLE. People trying to complete a task, or achieve a goal, and trying in some way to get value from our software products. Yet as software developers we continue to forget that humans are the main point of our products and so we make the 'user' subject to our convoluted and inhuman 'business logic' and esoteric architectures.
    </rant>
  10. Objective HTML - An alternative to the MVC[ Go to top ]

    Thanks for your input Toby.

    The comments you made about dividing the work into front-end and back-end teams are absolutely correct. I too have worked on projects like this. I'm not sure what you exactly define as the front-end, but for me I would say that should include the html/javascript, JSP/bean and also the Controller layer (the web tier basically). The back-end for me means the Session Beans, EJBs, SQL, JMS, etc. And that is exactly the setup the toolkit I have written caters for. The toolkit only works with the Html form presentation and data. Essentially its the View/Model and Controller (some of it anyway). No where have I stated that you business logic could not be abstracted away in SessionBean or another simple Java class for that matter.

    What I've done is just made handling of form data more easy and given html entities some OO properties.
    For e.g. say you have a select list box on your form and the form is submitted. The next screen you wish to load has the same form but with list box item selected. With the standard jsp/bean/controller approach you would have to extract the submitted data from the request object. Copy it to the bean, do some processing on it. Then pass it back to the bean. The jsp then gets the data from bean, does some kind of for loop searching for the selected item and sets the item as selected. In my toolkit you don't need to do that at all, as long as you call updateData() all the fields are updated accordingly with the posted data (see example on the project website). An example of OO properties is that all control objects (input, select, textarea, etc) have auto-escaping of html entities. Its all automatically escaped for you with out you having to do anything.

    Have a look at the example in detail, I'm sure you'll be able to see that you can still apply your ideas of work division.

    Keith
  11. Keith,

    I'm not sure what you refer to with "standard jsp/bean/controller" approach, but here's how you'd do the JSP part of a form using the WebWork framework:
    <form action="someaction.action" method="POST">
    <table>
    <ui:textfield label="'Username'" name="'user'"/>
    <tr><td colspan="2" align="center">
    <input type=submit value="Update">
    </td></tr>
    </table>
    </form>
    --
    I.e. form fields are done using JSP tags. This gives you a short and clean syntax for adding form fields. Now, that tag does not have any out.print() statements, but rather does an include of a JSP fragment. This has several effects:
    * The GUI designer can change the l&f of all forms on a site by simply changing these fragments.
    * You can have several concurrent "themes" by simply switching what set of fragments to use. The themes can either be graphically different, or for different kinds of browsers (e.g. HTML, XHTML, CHTML, WML).
    * The extraction of data and looping and all that is performed in the fragments. This is done once, so there's no per-form code to be written.
    IMHO this is a much better approach since it gives the GUI designer complete control over how things are rendered, while still keeping a structure that can easily handle the processing part of it.

    /Rickard
  12. Hi Rickard,

    I'm not saying there's anything wrong with the approach you have used. The issues I see with this approach is that your form data and presentation logic are highly decoupled. Say for example you run some business logic which results in you having to disable some fields in the form. Using the structure you presented you would have to create some flag (from the controller) and the set it in either your Bean (your model) or have some flag in the request object. The flag would then need to extracted by the Jsp somehow (be it scriptlets or custom tags) at a later stage. In a simple case this isn't too bad, but in a complex form you might have different fields you need to disable or remove (or something else) and the only way to do that from the controller is to have these flags passed down to it either from the Bean or request object. Is that not very messy!? From a design point of view its kind of weird because at the controller level you know how the fields need to rendered, but you don't have any control of the rendering until a few layers later at the Jsp. Using ohtml toolkit at the time you know the fields need to be disabled or hidden (or whatever) you can do it then and there! Essentially your approach has decoupled the model/view/controller components to the extremist level. To me this doesn't fully make sense because these components actually do have a relationship with each other! The ohtml toolkit is quasi-MVC implementation, I have tried to decouple the components that make sense but I've also tried recoupling the components that should work closer together. I know you have issues with the presentation and the business logic being to tied in together, but there are ways around it. In my example CustomerForm extends HtmlForm. But what you could do is have CustomerFormBase extends HtmlForm and in this class just implement the constructor (i.e. it will contain all the code to setup how the form looks, components, etc.) and then have CustomerForm extends CustomerForm and have all your business logic code in this class! This way your presentation and business logic has become seperated using OO.

    In the end I think your solution does have merits in some situations but if your web application is very form intensive (a lot data entry/data viewing) then ohtml toolkit does offer some benefits.

    btw. As for the "themes" thing you mentioned, I'm working on having the objects be able to write xhtml as well as html.

    Keith
  13. Here's what the JSP for dynamically disabled form fields would look like with WebWork:
    <form action="someaction.action" method="POST">
    <table>
    <ui:textfield label="'Username'" name="'user' disabled="disabled('user')"/>
    <tr><td colspan="2" align="center">
    <input type=submit value="Update">
    </td></tr>
    </table>
    </form>
    --
    and the code to disable the field:
    ..
    Map disabled = new HashMap();
    public Map getDisabled() { return disabled; }
    ..
    public String execute()
    {
     ..
     disabled.put("user", Boolean.TRUE);
     ..
    }
    --This allow you to turn off individual fields in the form without having to have strong coupling between the controller and the view, and there's no model modifications whatsoever. IMHO it's not messy :-)

    You're trying to make your case based on assumptions of what messiness *have to* occur in the controller, model, and view layer to make this happen. You continously make general statements of how an approach != ohtml would work, whereas you would really have use an explicit example with a particular framework to not be wrong. In this case (and many many more), WebWork has simplified that *potential* messiness to the point where it's really not that bad.

    /Rickard
  14. Well fair enough the code doesn't look that messy, but the code you've supplied is still generally what I described in the previous post. Ok you don't need to change your model, but generally you still need to pass a boolean from the controller layer out to the Jsp layer via the Model. And since we're pasting code, this is how my code would look:

    m_txtUsername.setDisabled(true);

    You stated that you haven't strongly coupled your controller and view, but you've only acheived this at a syntatical level. At a logical level they are very much coupled by the fact that you're wanting to disable the "user" field from the controller but this doesn't happen till the view level. So you trying to make something that is logically coupled into something that is not? Just seems a bit funny to me.

    As for the general statements, what else would you expect me to be doing? I'm not exactly going to argue against all the possible frameworks out there, I could be here forever. I'm just trying to state some generic examples that has a similarity for most developers.

    As I said before, your way has some good points but so does mine, especially for web apps that are form and data intensive.

    Keith
  15. Keith,

    With your architecture, how would i go about forwarding to another jsp. Your example only contained the one jsp, right now the place i work at is using struts, but i wanted to give this a try and wanted to see which i like better.

    Thanks,
    Jeff Cooper
  16. Hi Jeff,

    I'm glad your going to give ohtml a go. :)
    Perhaps you can email me and send some code too, it really depends on the architecture you want to use. If your using a page-centered architecture then you can just use a http forward. If you have a more dispatcher like architecture where you got a central entry point and you farm off the request then you just simply create the form you want and load that page. I only know struts from a high-level but I'm sure you can fit in my toolkit into their framework. They have a very good way of farming off requests to the appropriate controller.

    Keith
  17. Actually Object HTML is alternative to HTML but not MVC. MVC is an architecture , but not an Object HTML.
  18. That comment has been made before.
    OHtml doesn't cover the complete MVC architecture, but it offers more than just an alternative to Html. When you create a html form in OHtml, the form encapsulates your view, your model and parts of your controller. It allows you to access your view from your controller, something that the controller class, bean class, jsp page solution doesn't provide.
  19. Objective HTML - An alternative to the MVC[ Go to top ]

    Here's a great white paper on the subject of why "objective HTML" is better than JSP from the company that wrote a commercial implementation called Hammock.

    http://www.netdecisions.com/our_work/our_research.asp?os=nt&browser=ie&version=5.5&flash=yes#

    IMHO if you're building a "web application" Objective HTML is a better long term solution. If you're building a "dymanic web site" or there are mostly web designers on your staff JSP is a better tool.
  20. Objective HTML - An alternative to the MVC[ Go to top ]

    Thanks for the link Tad,
    I thought I was going it alone there for a while! :)