Hi Jon,
Just my 2c. Something you might want to think about.
We had a similar problem at Opticode. Designers ended up bugging java
people a lot - mostly me :-) and we ended up adding a lot of utility classes
in the context for each screen (pull strategy), but somehow this never
seemed to work well enough. We needed a fresh approach.
This was the rational behind the JPyton integration. Because all our
designers had at least basic programming ability we felt that we could allow
them to program screens themselves. Python is sufficiently easy to learn,
but still boasts full OO support, which made it the perfect candidate.
The way it is working now is that we expose certain java classes to the
JPython scripts (usually the Peer classes and some general usage classes)
which allows a developer to do the screen programming, but still in a
controlled environment. JPython classes can inherit from java classes that
allows us to use the one-on-one screen/template approach currently available
in Turbine.
When caching is turned of the Python script gets interpreted with each page
request. This makes compile/testing/debugging phases a lot easier. When
caching is switched on only the first hit results in the interpreter
execution. From there on performance is on par with normal java screens.
We've been working with JPython screen scripts a bit and we can already see
the benefits. As an added bonus of the AssemblerBrokerService it is
theoretically possible to do actions, layouts, etc. in Python as well (busy
testing it).
The JPython stuff is probably stable enough to be added to the main cvs
tree, but I haven't had time to write some docs and examples yet. If you
want I'll make this a priority and get it into the cvs ASAP.
~ Leon
> Hi all,
>
> <READ THIS FIRST>
> Sorry for the cross posting, but I think that this is important to bring
up
> the issue across a few lists. If you would like to discuss this, please
> subscribe to and only respond to the Turbine mailing list. You can
subscribe
> by sending email to [EMAIL PROTECTED]
> </READ THIS FIRST>
>
> This document is to explain a different type of philosophy for working
with
> Context based MVC tools like WebMacro (WM) and Velocity (V) than I think
> that the Turbine community is used to. The requirement for this philosophy
> has come up recently during Scarab development and I would like to share
and
> document it with you all. Many thanks to Brian B for being patient with me
> and trying to explain exactly what he wants to see. So, let me start off
by
> giving a little bit of history and then moving on from there...
>
> The current encouragement that Turbine gives to developers is to do a
> mapping between one Screen (Java) and one Template (WM or V). The way it
> works is that you build up a Context object that is essentially a
Hashtable
> that contains all of the data that is required to render a particular
> template. Within the template, you refer to that data in order to format
it
> for display. I will refer to this as the "Push MVC Model." This IMHO is a
> perfectly acceptable, easy to understand and implement approach.
>
> We have solved the problem of being able to display the data on a template
> without requiring the engineer to make modifications to the Java code.
>
> However, it has a shortcoming in that it makes it more difficult to allow
> the template designer (ie: a non programmer) the ability to move
information
> on a template from one template to another template because it would
require
> the logic in the Java code to be modified as well. For example, say you
have
> a set of "wizard" type screens and you want to change the order of
execution
> of those screens. In order to do so, you can't simply change the Next/Back
> links you need to also change the Java code. This is bad because at least
> for CollabNet, our clients will require us to provide that ability.
>
> So, beginning with Scarab, I am 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 "global" set of objects
available
> for the template designer to pick and choose from. Gone are the days where
> one would have a Java class that would be responsible for building the
> context up for the template. Instead, there would be a single base class
> that stuffs these objects into the context for every request and there is
a
> documented API that the template designer can refer to in order to access
> the information that he/she needs to get at. Of course this information is
> only retrieved when requested and can also be managed in a cache for
reuse.
>
> By moving to a "Pull" model, it becomes possible to more easily achieve
> complete independence from the Java engineers in order to not only change
> the look and feel (UI) of the site but also the information architecture
> (IA) layout and flow of the site.
>
> While this puts more requirements on the Java engineer to make sure that
the
> template designer has a well defined API, it will save the Java engineer
> many hours further down the road when the client requests IA changes
because
> now the responsibility is on the template designer to make the changes.
>
> 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.
>
> I'm going to start working on a framework that will make it easy to create
a
> container framework for these objects that will allow them to easily deal
> with the multithreading issues as well as the caching issues involved with
> these objects. I suspect that I will be able to rely on Turbine's Services
> model as well as Turbine's Global cache model for the basis of most of
this
> code.
>
> Comments are appreciated.
>
> thanks,
>
> -jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
