Discussions

TSS feedback: Need a separate thread/discussion for post testing

  1. In fact, I am doing my testing right now. Never could get tables properly... so, take one:

    <br>
    <table border=1 cellspacing=0 cellpadding=4 width=100% style='background:#FFFFCC'>
     <tr>
      <td width=20% valign=top>&nbsp;</td>
      <td width=40% valign=top>Header A</td>
      <td width=40% valign=top>Header B</td>
     </tr>
     <tr>
      <td valign=top>Criterion 1</td>
      <td valign=top>Bla bla bla</td>
      <td valign=top>Bing bling bling</td>
     </tr>
    </table>

    Threaded Messages (9)

  2. Indeed[ Go to top ]

    Gee, did not work...
    <table border=1 cellspacing=0 cellpadding=4 width=80%>
     <tr>
      <td width=20% valign=top>&nbsp;</td>
      <td width=40% valign=top>Header A</td>
      <td width=40% valign=top>Header B</td>
     </tr>
     <tr>
      <td valign=top>Criterion 1</td>
      <td valign=top>Bla bla bla</td>
      <td valign=top>Bing bling bling</td>
     </tr>
    </table>
  3. Indeed[ Go to top ]

    Well, it is autoescaped. How can I insert a table?

    | Header A | Header B |
    ---------------+--------------------+--------------------+
    Criterion 1 | Bla bla bla | Bing bling bling |
    ---------------+--------------------+--------------------+

    Hello, good old terminal.
  4. Indeed[ Go to top ]

    PRE did not work, what about CODE:

    <code> | Header A | Header B |
    ---------------+--------------------+--------------------+
    Criterion 1 | Bla bla bla | Bing bling bling |
    ---------------+--------------------+--------------------+</code>
  5. Oops[ Go to top ]

    Info about inserting tables will be highly appreciated.
  6. Indeed[ Go to top ]

    Michael, we don't support posting tables inside our discussion threads. The most you'll get is bulleted lists.

    Sorry,

    Floyd
  7. How about images[ Go to top ]

    <img border="0" src="http://www.jroller.com/resources/javadujour/ewstatemachine03.gif">
  8. How about images[ Go to top ]

    that sucks...
  9. How about images[ Go to top ]

    Yes, one has to create a bunch of objects/artifacts to make even one simple page, and Stipes is better in this sense. Can Struts be improved? Sure. Stripes has a simple return new ForwardResolution("/bugzooky/BulkAddEditBugs.jsp"); object to forward to a view. Great, but one does not have to use indirection like return mapping.findForward("success"); in Struts either. Just create a new ActionForward object on the fly. Events can be easily mapped to methods with some sort of DispatchAction, while not so simple as with annotation, that is true. But mapping through a separate file is more flexible. Whether you need the flexibility or not is another question.

    Incremental development. Yes, in Struts a JSP cannot be previewed if bean data is not initialized. This calls for updates and fixes in Struts. But a new framework?

    Property binding. "Struts lets you use nested properties, and that's great. But say you have a property on your Form 'person.address.line1'. Struts will try and set it for you, but if person or address is null, you'll be very sad indeed." Again, this issue is the perfect candidate for improvement in Struts.

    Validation. "Validation in Struts is divorced from Type Conversion. This is just plain wrong. Why validate that something is a well formed date, then spend a whole bunch more effort converting it to one?" I am not happy with Struts validation either, but at least I am free to do whatever I want with input data. I can define string properties and go wild. Also, there is a project, which tries to solve exactly this problem: StrutsLive!. Instead of devising own framework, it would be better to evaluate and maybe include StrutsLive! or portions of it into future versions of Struts.

    Null mean Null. "Ask yourself this. You have an int property in your form bean and the user doesn't enter a value in a text box. What should your property be set to?" Right, Struts uses default values for non-string properties. The answer is using string properties only. This is what I do and it gives me full control over input data. Try the aforementioned StrutsLive! project for automatic validation, or check out FormDef project.

    Formatting. "The Struts FAQ says this (among other things) in answer to why the Struts tags provide so little formatting: First, work started on the JSTL and we didn't want to duplicate the effort. Second, work started on Java Server Faces, and we didn't want to duplicate that effort either. Third, in a Model 2 application, most of the formatting can be handled in the ActionForms. ... Great. JSTL doesn't have form tags, so while JSTL is great, it doesn't really help here. JSF and Struts don't mix so well even now, and that's a reason to leave people without formatting for years? And the last is just a cop-out."
    Right. So, why not to solve this issue for Struts users instead of creating a brand new framework? Why not to submit patches to Struts codebase? See aformentioned FormDef project, which performs data formatting, data conversion and locale support.

    Multi-Event Actions. "If you want to have a form that submits multiple different events in Struts you have to either extend the DispatchAction or write your own support for it. And since the DispatchAction requires all buttons to have the same name, and uses the value to determine the method to invoke, it's a huge pain if you're using localized or even just externalized values for your buttons." Multi-event actions are easy with Struts Dialogs library. This library also allows to create simple JSP components using two-phase request processing.

    JSP / View Helpers. "Struts doesn't really provide a good pattern for providing dynamic data to JSPs that are not the result of another Action. This leaves you with the options of writing a pre-action for the page or doing something outside of Struts." Struts Dialogs provides an easy development approach with only one action class per web resource, so supplying view data and collecting input data is easy.

    "HTML" Tags. "Maybe it's just me who could never get used to it, but why do the Struts form input tags use 'property' instead of 'name'? And why is it 'styleClass' instead of 'class'?" The reasons were explained in Struts mailing list, while I accept styleClass, I dislike property instead of name. And the docs for Struts tags beg for improvement. This is what I would rather see instead of another framework announcement.

    From what I've read so far on Stripes, it is not so much different than Struts, so I don't see a point converting. On the other hand, if I decided to abandon Struts, I would rather try something completely different, like Tapestry or Wicket. Nevertheless, I wish Stripes all the best, the framework market is tough as never before ;)
  10. How about images[ Go to top ]

    Yes, one has to create a bunch of objects/artifacts to make even one simple page, and Stipes is better in this sense. Can Struts be improved? Sure. Stripes has a simple return new ForwardResolution("/bugzooky/BulkAddEditBugs.jsp"); object to forward to a view. Great, but one does not have to use indirection like return mapping.findForward("success"); in Struts either. Just create a new ActionForward object on the fly. Events can be easily mapped to methods with some sort of DispatchAction, while not so simple as with annotation, that is true. But mapping through a separate file is more flexible. Whether you need the flexibility or not is another question.

    Incremental development. Yes, in Struts a JSP cannot be previewed if bean data is not initialized. This calls for updates and fixes in Struts. But a new framework?

    Property binding. "Struts lets you use nested properties, and that's great. But say you have a property on your Form 'person.address.line1'. Struts will try and set it for you, but if person or address is null, you'll be very sad indeed." Again, this issue is the perfect candidate for improvement in Struts.

    Validation. "Validation in Struts is divorced from Type Conversion. This is just plain wrong. Why validate that something is a well formed date, then spend a whole bunch more effort converting it to one?" I am not happy with Struts validation either, but at least I am free to do whatever I want with input data. I can define string properties and go wild. Also, there is a project, which tries to solve exactly this problem: StrutsLive!. Instead of devising own framework, it would be better to evaluate and maybe include StrutsLive! or portions of it into future versions of Struts.

    Null mean Null. "Ask yourself this. You have an int property in your form bean and the user doesn't enter a value in a text box. What should your property be set to?" Right, Struts uses default values for non-string properties. The answer is using string properties only. This is what I do and it gives me full control over input data. Try the aforementioned StrutsLive! project for automatic validation, or check out FormDef project.

    Formatting. "The Struts FAQ says this (among other things) in answer to why the Struts tags provide so little formatting: First, work started on the JSTL and we didn't want to duplicate the effort. Second, work started on Java Server Faces, and we didn't want to duplicate that effort either. Third, in a Model 2 application, most of the formatting can be handled in the ActionForms. ... Great. JSTL doesn't have form tags, so while JSTL is great, it doesn't really help here. JSF and Struts don't mix so well even now, and that's a reason to leave people without formatting for years? And the last is just a cop-out."
    Right. So, why not to solve this issue for Struts users instead of creating a brand new framework? Why not to submit patches to Struts codebase? See aformentioned FormDef project, which performs data formatting, data conversion and locale support.

    Multi-Event Actions. "If you want to have a form that submits multiple different events in Struts you have to either extend the DispatchAction or write your own support for it. And since the DispatchAction requires all buttons to have the same name, and uses the value to determine the method to invoke, it's a huge pain if you're using localized or even just externalized values for your buttons." Multi-event actions are easy with Struts Dialogs library. This library also allows to create simple JSP components using two-phase request processing.

    JSP / View Helpers. "Struts doesn't really provide a good pattern for providing dynamic data to JSPs that are not the result of another Action. This leaves you with the options of writing a pre-action for the page or doing something outside of Struts." Struts Dialogs provides an easy development approach with only one action class per web resource, so supplying view data and collecting input data is easy.

    "HTML" Tags. "Maybe it's just me who could never get used to it, but why do the Struts form input tags use 'property' instead of 'name'? And why is it 'styleClass' instead of 'class'?" The reasons were explained in Struts mailing list, while I accept styleClass, I dislike property instead of name. And the docs for Struts tags beg for improvement. This is what I would rather see instead of another framework announcement.

    From what I've read so far on Stripes, it is not so much different than Struts, so I don't see a point converting. On the other hand, if I decided to abandon Struts, I would rather try something completely different, like Tapestry or Wicket. Nevertheless, I wish Stripes all the best, the framework market is tough as never before ;)

    References:
    StrutsLive
    FormDef
    Struts Dialogs

    For StrutsLive and FormDef use https. For some reason TSS does not allow to link to secure site.