I have some questions regarding the development process when using JSF, especially in realtion to HTML designers. Will everyone on the team need the same advanced design tools? Will the designers who are used to tweaking HTML/JSP be restricted to a completely visual drag and drop environment? Or even worse, will the HTML designers be required to learn JSF mark up code?
There was another thread a few weeks ago relating to the general development process. Like many others, we have gotten used to the process where the HTML designers mock up a page and then a software engineer transition the page to a JSP and wires it into our system (using Struts, and JSTL). What is the vision for the development process in JSF? Also, what is the ultimate vision for JSF? Do you invision a IDE that can create interfaces on the same level as Flash? A question asked earlier in this thread: Will JSF integrate with Flash forms? It would be cool to have one integrated development system that could do it all. This thread was started with the question, "If you were starting a project today, what would you use, Struts or JSF?" My answer is, I would use Struts with JSTL and I would purchase the new Eclipse based IDE, NitroX (http://www.m7.com/). We purchased licenses for NitroX after our CTO came back from JavaOne. It looks like the creative people at M7 have done a lot of things right; they even have planned support for JSF. NitroX may very well evolve into the IDE that can do it all. The best thing about NitroX is that it will enable a transition from Struts to JSF if you decide to go that route. The main reason I would choose Struts/JSTL over JSF is that it works well within the existing skill sets of most developers and designers. I would keep an open mind regarding JSF, especially in regard to high level components that are not easily created using JSP/JSTL. This is the area where JSF could win the game. In the near term, my guess is that the really cool advanced interfaces are going to require Flash. If you'd like to see some leading edge Flash, turn up your sound and go to http://www.2advanced.com/ Mike --- Michael McGrady <[EMAIL PROTECTED]> wrote: > At 01:01 AM 7/19/2004, you wrote: > >The custom tags that Struts provides (in the html and logic and bean > >tag libraries) were a necessary precursor to "out of the box" usage of > >Struts, in order to make it possible to adopt the basic MVC > >architectural pattenrs. However, that was *always* a secondary > >feature in the original vision -- the important part was separation of > >the view tier logic from the business tier logic. > > > >Craig McClanahan > >(Original creator of the Struts framework) > > > As an original historical matter, it would be hubris of the highest variety > to question you on this, Craig. As a historical consequence, however, I > for one think that this turned out to be the more revolutionary result of > struts, leading coding into taglibs in a way not seen before. The > controller and MVC (of sorts) pattern in Struts existed in all sorts of > forms prior to Struts. Struts did it better than most, maybe better than > all the rest, and provided a standard that people could code to. But, > those tags were just a big surprise in the way they hit the market. I, for > one, now code tags as readily as I code classes. Not as many, of course, > but they are a definite weapon in my quiver. A big reason for that is that > I could code using Struts taglib code as a learning and doing mechanism > together. Blah, blah, blah. This is not meant to be particularly > profound. But I did want to give this boost to the tags in Struts. I > think they have been very important to Java. > > Michael > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
