Pull MVC
So, for discussion purposes, enter http://java.apache.org/turbine/pullmodel.html Specifically: So, beginning with Scarab, we are going to try another model which I will describe as the "Pull MVC Model". What this entails is the ability to create an object that is able to "pull" the required information out at execution time within the template. Thus, it becomes the job of the template designer to understand the API of objects available to him/her to take advantage of. Instead of the developer telling the designer what Context names to use for each and every screen, there is instead a set of a few objects available for the template designer to pick and choose from. These objects will provide methods to access the underlying information either from the database or from the previously submitted form information. Let's now think of the "API" as a business logic bean on your Action Form. Or a small number of coherent business logic beans that might be reasonably present on a given ActionForm. Then to access a given property, using the 10-JAN+ nested-property syntax, a HTML form designer might refer to apiModule1.thisProperty or apiModule2.thatProperty Now some of these "API beans" might be unique to a user (userPreferences.name), and others might be application-wide (actionMapping.login), and some might be relative to a given page-view, but to the page designer, they would all have a common "address space", that can be easily documented and understood. Of course, many of the API-bean methods could also be encapsulated in custom tags, to make things even easier on the page designer. But it might be helpful to have everything in a central place first, and optimize/customize from there. If developed in concert with a "conventional" application, it might also be possible for the API-beans to use a common interface and nomenclature, and share a great deal of code, with a traditional UI. (Since, of course, the business-logic API beans themselves should not depend on the Struts framework.) And, finally, to quote our Turbine friends, once again: I hope that this makes sense to everyone. I'm sure that some of you are probably saying "well, duh!." However, this is really not the model that has been encouraged so far within Turbine nor within other products such as XMLC (which actually operates *only* on the Push model), so I believe that it is somewhat uncharted territory for some people. The only products that I can think of right now that encourage this is JSP taglibs and Tea, however, I still feel as though they have missed the boat on this in one way or another. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
Re: Pull MVC
Ted Husted wrote: So, for discussion purposes, enter http://java.apache.org/turbine/pullmodel.html "Imitation is the sincerest form of flattery." :-) Seriously, the problems that Pull Model solves for Turbine apps was the primary motivation for implementing nested and indexed property handling in Struts. It's going to get even better if we succeed in implementing property getters that can transparently access information from a tree of Java objects (the current model), a JDBC RowSet, or an XML DOM structure -- all *transparently* to the page designer. For more powerful accessing capabilities, I also want to look at XPath expressions -- again, with the underlying data architecture being transparent, so that the business logic developers can remodel things to their heart's content. The only agreements that will be needed between business logic developers and page developers are the names of the action mappings, the names (and scopes) of the relevant beans, and the access paths to the relevant properties. Craig McClanahan
Re: App framework eval: Turbine and/or Struts - Push vs. Pull MVC
On Mon, 11 Dec 2000 22:25:59 -0800 Eric Brown writes: Ill let all know the results of the research my staff and I pursue in the following weeks, but Id welcome any feedback from users of these frameworks from architect, business layer development, UI layer development and ops perspectives. We will hopefully be contributors to some of these efforts in the future. Thanks for posting your chart, Eric. It will find a nice home in my own spec ;-). Besides the objective criteria, another important consideration is the philosophy of package and it's developers. Some of the major philosphical, or cultural, differences between Turbine and Struts is summed up nicely at http://www.mail-archive.com/turbine@list.working-dogs.com/msg02036.html This is a good case where reasonable people reading this could come away choosing one framework or the other, for equally valid reasons. When I choose something like a framework, I not only look at today's snapshot, but at the direction the package is taking in the long term. Another important consideration in an open source project is whether the development culture of Struts or Turbine is a good match with your own, in case you ever want to join the team of committers. Either package does the most important things, the question is whether it does them the way you like, and how easy it will be for you to add more of the things you like later. Some other threads related to choice of framework and architecture are: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00365.html http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00747.html http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00370.html -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
App framework eval: Turbine and/or Struts - Push vs. Pull MVC
Im looking for an application framework for future work at my company and am considering Turbine, Stuts and a few others. (My company currently uses IIS/ASP/SQL Server and will move to apache/Java app server, Tomcat first and Resin later as performance dictates, and Oracle.) Turbine seems to have the most features including Torque (DB abstraction) and a personalization engine that are important to me. However, as the push versus pull MVC paradigms (http://java.apache.org/turbine/pullmodel.html) recently discussed on the Turbine list concluded, Turbines preferred UI language, Velocity, is a push model that does not allow me to develop tag-like APIs for my UI/HTML designers the way struts does, a pull MVC model. I believe Turbine allows raw JSP that would allow me to use Turbine AND struts where appropriate although Im not sure thats the best answer either. Ill let all know the results of the research my staff and I pursue in the following weeks, but Id welcome any feedback from users of these frameworks from architect, business layer development, UI layer development and ops perspectives. We will hopefully be contributors to some of these efforts in the future. Thanks, Eric Eric Brown [EMAIL PROTECTED] -Original Message- From: Eric Brown Sent: Friday, December 08, 2000 7:04 PM Subject: Application Framework Evaluation Critieria Here are the relevant evaluation criteria Todd, Mark, Farooq and I discussed today: Priority Issue ASP Straight JSP Enhydra Struts Turbine XML/XSL 1 Separate UI from business logic XXX X XXX X 1 Database abstraction layer XXX XXX 1 Reliable, Stable and scaleable XXX XXX XXX ? ? ? 1 Growth path X XX XX XXX XXX XX 1 Error validation and reporting ? X? ? 1 Error message separation ? ? ? 1 Reasonably Fast XXX XXX ? ? ? X? 2 Very Fast XX XX ? ? ? ? 2 Personalization Engine X 2 Source code availability X X XX XXX X 2 Longevity -- Been around XXX XX XX X X X 2 Code reusability XXX XXX XX XX 2 Documentation XXX XXX XX X X XX 2 HTML form rich API ? X? ? 2 Early compilation XXX ? ? XX 2 Vendor Freedom X XXX XX XXX XXX XXX 2 MVC Pull model ? XXX ? 3 MVC Push model ? XXX XX 3 Strict API enforcement XXX XXX XXX 3 API Extensibility XXX XXX X XX 3 Internationalization ? X? X? X 3 File Upload API ? ? X? Ive tried to note what I know exists in each framework. The legend is as follows: X Feature exists XX Feature exists and is reasonably good XXX Feature exists and is great ? Feature might exist, unsure X? Feature exists but quality is unknown ASP IIS, ChiliSoft, Perl::ASP Straight JSP See www.javasoft.com Enhydra See www.enhydra.org Struts See jakarta.apache.org Turbine See java.apache.org XML/XSL M$ Implements on ASP, Cocoon (java.apache.org), Resin (www.caucho.com) Other priorities relevant to web server, internal process, etc., but not to application framework: Priority Issue 1 Staff Training Resources 1 Must run in J2EE environment (Tomcat 3.2) 1 Portability, ability to migrate from NT to UNIX easily 1 Security 2 Easy Deployment 2 Logging/audit system 2 Ability to debug 2 Search 3 Voice/WML/Alternate presentation format support 3 Reporting system 4 Content Management (other than Perforce) Eric Brown [EMAIL PROTECTED] Pri Issue ASP JSP Enhydra Struts Turbine XML/XSL 1 Separate UI from business logic XXX X XXX
