Announcement Announcement Module
Collapse
No announcement yet.
html5 tag library for jspx and roo? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • html5 tag library for jspx and roo?

    From my personal perspective the whole Roo product should use html5 as default from the document and template level to the smallest element. HTML5 Doctype seems to be default already in Roo1.2m1, but I don't see a clear way to use HTML5 tags where needed. Any ideas on how to accomplish this?

    Do anyone know of a HTML5 taglib for jspx or is planning for working on one? Such a lib would be very useful when working with real life web applications with jspx files as is the case with Roo generated applications.

    As jspx is xml — but which can certainly produce valid HTML— and html is not, a taglib would bridge the gap. The problem and some possible solutions including creating a html5 tagblib are mentioned here at Stackoverflow: How to produce valid HTML with JSPX? (not XHTML).

    Possibly something like this is already on the horizon but I see very little discussion on the subject so I wanted to bring this up. Anyone care to shed some light on the situation with Roo and HTML5 elements?
    Last edited by MiB; Nov 20th, 2011, 10:45 AM.

  • #2
    I made JIRA ROO-3005 "full html5 support" out of this. please vote for it.

    I'm really disappointed with the lack of responses. Everyone I know in the industry here in Sweden began using html5 only during 2009 up to now. Currently I know of noone not using it, making it the defacto standard for any outfit supporting IE6 and later generations of browsers.

    Why should html5 be second citizen in the Roo universe? There is some support, but not for all valid html5 like empty elements not being self closed, like link for instance.

    You are using html5? If so, how do you and your teams make it work with Roo and Roo generated views specifically?
    Last edited by MiB; Feb 1st, 2012, 01:58 PM.

    Comment


    • #3
      @MiB,

      Disappointed?...

      You can always checkout the source code and do it yourself. At this time probably you might know that open source won't solve you problem 100%. But it provides the code -at not cost- so you can do it.

      So when you think you could have the referred html5 taglib up an running?

      B. Roogards
      jD
      Last edited by delgad9; Jan 3rd, 2012, 08:47 AM.

      Comment


      • #4
        I was disappointed with the lack of responses, ie the willingness to discuss issues like this one. I'm not expecting anyone to develop something just for me and I'm surprised you could understand what I wrote this way. I do think the html5 support could be improved and that it is in the interest if the Roo team to do this. I'd like to hear what the Roo team thinks. They are very reasonable people no matter if they agree with the bug reporters perspective or not.

        I'd be willing to chip in coding stuff that others can use if it's within my interest too, but I'm not springsource. I'm using the CDATA solution so have little interest in a tag library specifically, but I don't think potential users with html5 requirements will feel impressed with this. I'm convinced that Roo without proper HTML5 support will fail. It can be argued the current situation with html5 support is as good as can be, but I don't think it is. I don't believe I do the Roo community a service not voicing my opinion. I want Spring Roo to succeed. Don't you?

        Seriously, what am I asking for here? I'm asking for full HTML5 support. If that is too much to ask for, then I'm grandma Duck. It's a reasonable request to make to springsource.

        I've expressed interest before in joining efforts to develop tag libraries to be shared among users, but I know of no such projects nor people interested in working on such.
        Last edited by MiB; Jan 3rd, 2012, 10:32 AM.

        Comment


        • #5
          Please provide a patch for html5 support and we will consider it.

          Comment


          • #6
            I couldn't venture into this without knowing how the Roo team so far have reasoned over html5 support. There is support for html5 to a certain extent today. It's just not full considering syntax. How does the Roo team look at the html5 support there is in the current version and what is the place of html5 in the Roo product?

            I don't use Roo tags for production myself — I feel they currently get in the way so I use the tag libraries of Spring which I love —and I'm not certain a tag library specifically is the best solution for html5 support either. Given that, I feel this is too close to the core concept of Roo for me to take an initiative at the moment. At least without knowing more about the thoughts of the Roo team on the matter of html5.

            Issues that I think of now is if such a tag library really is the best solution for html5 support, or whether some other solution might be best presented as an addon or as change to the core source?
            Last edited by MiB; Feb 1st, 2012, 02:01 PM.

            Comment


            • #7
              A potential temporary fix (at least for stream)

              MiB,

              Hey there.

              I saw your post, voted up the JIRA issue, but also did some experimenting with filters.

              We can generate the <!DOCTYPE html> entry this way:

              Code:
              public class Html5Interceptor extends HandlerInterceptorAdapter {
              
                @Override
                public void postHandle(HttpServletRequest request,
                                       HttpServletResponse response,
                                       Object handler, ModelAndView modelAndView) throws Exception {
                  response.getWriter().println("<!DOCTYPE html>");
                  // this was the crux of the matter - if you don't flush this doesn't get sent
                  response.getWriter().flush();
                  super.postHandle(request, response, handler, modelAndView);
                }
              
              }
              Then, mount the interceptor in webmvc-config.xml:

              Code:
              <mvc:interceptors>
                  <!-- the new one -->
                  <bean class="com.chariot.dojodemos.mobile.web.Html5Interceptor" />
                  <bean class="org.springframework.web.servlet.theme.ThemeChangeInterceptor"/>
                  <bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" p:paramName="lang"/>
              </mvc:interceptors>

              Comment


              • #8
                AAAAAAAAAAnnnnnnd...

                THAT was a naive approach, me thinks. I'm getting flush errors hitting anything other than the main page, but who knows.

                Also, anything with data-dojo-xxx won't work with the roo tags off the bat, because JSPX tag libraries have to pre-declare everything. I guess we could do data-dojo-type and the options one (forget the name) on each widget and defer to it, or edit the widgets to do this instead of the embedded Javascript.

                I just created a JIRA ticket on the Spring MVC layer asking to provide safer support for non-JSPX Roo users. Right now, if you create a controller for example, Roo will add back in the Tiles components. You can't install Spring Security without the JSPX web layer being configured properly, etc... Someone needs to go through those and make them more tolerant, perhaps making sure Roo doesn't change anything by default (but has a --resetConfiguration true) option or even a command like 'web mvc reset-configuration'...

                I wrote some of this up in https://jira.springsource.org/browse/ROO-3045. I think once we can get Roo to demure where it needs to in the configuration of the web tier, and be more flexible as to the style of view configuration chosen, etc., it will really be a stronger choice for cases where the scaffolding is maybe 20% of what you need to code, or where regular JSPs or other technologies are a better fit.

                Ken

                Comment


                • #9
                  Thank you for your thoughts and ideas, Ken. I voted for your improvement request.

                  Case in point is that I can't seem to get mediaelementjs — as audio only — to work with the jspx pages that Roo produces, so I build the whole app without it and then replace every jspx page needing this with jsp pages structured with Tiles as the others.
                  Finally I couldn't stop there as that would mean I would have to double all my templates and Tiles and in the end experiences like this led me to abandon jspx everywhere. It's stuff like this that makes me feel that the Roo interface is mostly useful for mockups. This might be different for people who have XHTML requirements.

                  I'm now investigating Freemarker and Velocity as alternatives for my pages, though jsp feels alright for smaller sites at least.

                  I'm still not sure what the best place for HTML5 in Roo is, but seems to me this should be in the core as an alternative. I already know this would likely break the possibilities for Roo to be able to separate user edits from model generated parts, but it would still be useful. Or possibly a html5 tag library could be made. And right now this is likely to have to be a community effort. I'm asking myself if that could really work?

                  I'm a bit bewildered by the Roo community. It seems natural some issues should be worked on jointly, but I'm not familiar on how this should work nor where to get started to find the proper people to work with. Personally, I'd join a HTML5 project, but I couldn't head it I think.
                  Last edited by MiB; Feb 1st, 2012, 03:16 PM.

                  Comment


                  • #10
                    MiB

                    I ended up ripping out all the Web layer stuff ROO had created for me and started the Web Layer from scratch, and it is working incredibly well. I have just the first page as jsp page rendered when going to my app. Then everything after is JQuery/Ajax REST calls.

                    I also found the best Templating that doesn't require any setup except loading the .js file in the page. It is called ICanHas.js, basically it is Mustache.js with extra simplicity added to it. (Odd statement there) They have templates and partials, way better than Tiles.

                    I think the only ROO I have left, which I pushed in is the getters/setters, in my domain objects and the basic xml Spring config files.

                    Mark

                    Comment


                    • #11
                      @bytor9999,

                      Ouch. At least you didn't have to use ejb again...

                      Congratulations in the way you figured your implementation. Everywhere I turn there are more-and-more community developers using JQuery/Ajax REST as a solution.


                      B. Roogards
                      jD

                      Comment


                      • #12
                        recommended new html5 jquery css3 web tier add on feature.

                        I strongly want use pure html5 + jquery + css3 not use jsf or gwt or jsp web tiers!!! so i recommende this new feature to roo. hold this will add

                        Comment

                        Working...
                        X