Announcement Announcement Module
No announcement yet.
struts or tapestry Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • struts or tapestry

    If you use spring which MVC frameword is better ?(struts or tapestry)

  • #2
    Struts1 or Struts2, what about SpringMVC as well?


    • #3
      Hello zengwenliang

      If you use spring which MVC frameword is better ?(struts or tapestry)
      you can work with spring mvc and any other framework (struts or tapestry) in the same time??, yes

      but it is a waste of resoruces for the server

      spring mvc is enough and is better than struts.
      spring mvc against tapestry??, i never work with tapestry

      now spring with Spring (not spring mvc) is a good option.



      • #4
        Have you checked this out?


        • #5
          Is struts the most populate MVC framework now?

          Is struts the most populate MVC framework now?


          • #6
            Originally posted by zengwenliang View Post
            Is struts the most populate MVC framework now?
            Its a very subjective question and I think it probably depends on who you ask. I think I'd go with the one that I've used before and know will do the job, or the one that best suits my requirements.


            Struts 1 is recognized as the most popular web application framework for Java.


            • #7
              Originally posted by zengwenliang View Post
              If you use spring which MVC frameword is better ?(struts or tapestry)
              As someone has already mentioned, there is no clear answer to your question. It very much depends on the nature of the application and its size along with scalability requirements. Generally there are 2 types of Web frameworks - the action based ones like Struts, Spring MVC etc. and the component based ones like Tapestry, JSF etc. Mix and match is also possible - hence u can guess the complexity . I had done some blogging on this - hence the shameless plug here.

              Of course it gives my stack of choice.



              • #8
                struts is crap, it's just popular because it's old and a lot of managers like stuff like that despite how lousy it really is

                tapestry is weird - i read somewhere that a big thing behind it's design was to keep the web pages like html, so the html designer can still have her syntax coloring. and to do that it makes the java programmer do a bunch of weird stuff. also it's a component framework, which is like putting a square peg in a round hole. it's weird i didn't like it, but maybe you will.

                i went through this same thing a while back and finally settled on stripes. - and let me tell you what it is beautiful. i couldn't have made a better decision.

                i looked at them all (well almost all i guess ... every 10 mins someone comes out with a new java framework) and stripes definitely was way ahead of the curve. the big reason for that is how it leverages annotations. stripes is a lot like struts (same sort of patterns within it), it's just newer and makes a hell of a lot more sense.


                • #9

                  struts crap???, mmm, the crap cant survive long time (instead of microsoft, a really crap),
                  anyway the true is that Struts is popular and cover the enough requeriments for a java web developer mvc

                  i heard an excelents references about stripes, and you right is beautiful (i never use it ), but by sentide common a new tool or framework must be better than other olders

                  now the new question should be which is better your beautiful stripes or spring mvc and why?



                  • #10
                    Moved this thread to the architecture discussion forum (where it actually belongs).

                    As for what should be used - struts or tapestry - seek the forum. The debate is a long one and it's not really fair since tapestry uses a different architecture then struts - they have different concepts and all in all belong to different time 'zones'.


                    • #11
                      IMO, tapestry sucks at almost any level.


                      1. non-surprisingly it uses Hivemind ( *embedded* IoC container) where the DI happens based on a CGLIB code enhancement of your abstract classes making the later quite difficuilt to unit-test

                      2. the API is bound to the HTML only. You could find a method description like: "this method prints out the text in RED"!!!

                      3. All *low-level* servlet-API objects are wrapped into some bizzare tapestry classes, which appear to be almost useless.

                      4. The promised ease of HTML-coding wears out immediately, if you start divide you templates into re-usable parts. For a Java-unaware web-designer it turns into a nightmare, as soon as he would need to mock each and every module.

                      The conclusion: the tapestry is good only for trivial HTML-based apps.

                      Unfortunately, we are employing it now, but I'm struggling to getting rid of it and switch to Spring MVC + WebFlow.


                      • #12
                        I'll stick up for Tapestry (a bit at least). It has problems, but I don't think the ones that Injecteer mentions are terribly significant. Unit testing is actually quite easy with the tools provided by Tapestry / Hivemind, and in fact it is easier given the abstraction from servlet domain which gives the "bizarre tapestry classes" some context.

                        However, I totally agree that HTML templates do not deliver on the advertised goals. Any reasonably complex component or component library will quickly bring the HTML back into the domain of the Java developer again. Plus it doesn't even produce valid HTML, except possibly against the very loosest DTD, which these days is a drag.

                        The most interesting feature of Tapestry is shared with JSF, viz: it is a component-based, event-driven architecture. This should be enough to make anyone sit up and listen. Unfortunately I think there are some problems with the way that Tapestry is implemented, but that is not to say that the idea is bad.

                        And Webflow could be the answer to all our prayers, I guess. Or maybe JSF. Or both.


                        • #13
                          Originally posted by david_syer View Post
                          And Webflow could be the answer to all our prayers, I guess. Or maybe JSF. Or both.
                          Any references/pointers about the integration of WebFlow and JSF ?


                          • #14
                            well, I agree with David, that those tapestry's probs are not very significant, but annoying.

                            Recently I took over a wep-app, where the front-end is written in tapestry. That looks, umm... strange.

                            Imagine, you have a single hige and chaotic JSP page, where there a lot of java-code, that accesses all your services, including the database directly. Then, the whole mess is converted into a tapestry structure, and the *funniest* point here, that the mess REMAINS! For example the following objects get injected there via DI:
                            - a couple of DAO's
                            - a hibernateTemplate
                            - a TransactionManager
                            - the Spring context itself!!!
                            the other pages (40+) have pretty much the same layout.
                            So, after looking at the system, I got a feeling that tapestry doesn't really encourage developers to write nicely layered code.

                            Another major drawback is that the MVC's Model and Controller are tightly bound together in tapestry. That means that the controller gets bound to the HTML and tapestry's UI-elements.
                            Another concequence is, you cannot change not only the media/format, but also the presentation technology.
                            Another limitation of a controller I saw in an implementation of a wizard. The guy to enable sequence navigation put something like:
                            pageBean.setPage1( false );
                            pageBean.setPage2( false );
                            pageBean.setPage3( true );
                            pageBean.setPage4( false );
                            pageBean.setPage5( false );
                            and had to repeat it on every wizard's page.

                            I'd use an existing wizard-enabled controller here, like Spring's one, but with tapestry you cannot use a controller and view technology other than tapestry's own ones!

                            btw, some more about those 'bizzare tapestry' wrappers. A simple example: in my web-app I have 2 tapestry servlets, serving two independant sub-apps. Then I had to set a non-default session timeout for one of them.
                            In a plain servlet I'd make it with session.setMaxIncativeInterval(), but in the tapestry wrapper this method is not available. So, I had to split the web-app in 2 applications only to enable different timeout values.