ANNOUNCE: JOTWeb 1.11, preview of new web application system.

[Dave Cole]

>>>>> "Sean" == Sean Reifschneider <jafo at tummy.com> writes:

Sean> On Wed, Jun 18, 2003 at 08:44:27PM +1000, Dave Cole wrote:
>> Or you could use one of the application classes to reduce the code
>> needed for each page.  Assuming you have more than one page in the
>> application.

Sean> There were no examples demonstrating that...

One thing I have discovered is it takes a lot more effort to document
these toolkits and build examples than it does to build the actual
toolkit.

Sean> Sure, I'd love to spend a couple of weeks getting really
Sean> familiar with all the different web application frameworks out
Sean> there so that I could really make an informed decision based on
Sean> the implementation of a represenative application.  However, if
Sean> I had 3 months off work I'm not sure I'd spend it re-writing a
Sean> web app a dozen times...  :-)

Can't argue with that.  If I was to guess the outcome of the
investigation you would probably find that each toolkit had strengths
and weaknesses.  You would also probably find that most (if not all)
had a niche where they were better than all of the others.

>> When it comes down to it, the number of lines in a trivial
>> application is not why you use toolkits and frameworks.  You use a
>> framework to help construct a complex application.

Sean> Adding complexity to every page in a complex application is also
Sean> a serious problem.  It means that every time I have to look at
Sean> some page code, I have to understand what's going on in this
Sean> setup code.  It also means that if I set up one page that has
Sean> different setup code, I'm likely to miss it unless I read all
Sean> the code fairly carefully.

Again there is no argument here.  I might add that if the setup is not
purely exposing data to the templating then there is no way that the
toolkit will be doing that work for you.  That means that the code has
to be provided by the application and has to reside somewhere.

If I read your comment correctly you are making the point that it is
preferable to glue the pieces of application code together by
references in the templates:

   <span tal:replace="code/currenttime"></span>

which then implicitly imports code.py and invokes currenttime()

In Albatross the glue at that level is all in Python, and in your
application.  This means that you have to do a little more work in
locating the code that provides the currenttime() function.  No big
deal really.

    from myapp.utils.code import currenttime

    def page_display(ctx):
        ctx.locals.currenttime = currenttime
        ctx.run_template('time.html')

The the template calls the function (if you want to do it that way).

In Albatross the toolkit locates and loads the single Python module
that is responsible for responding to a browser request.  Once that
module has been loaded the application programmer is then responsible
for importing all of the other Python code used to respond to the
request.

>From your example above, JOTWeb takes a much finer grained approach in
that the template identified by the browser request pulls in Python
code fragments from a namespace structured by the file system.

Sean> I *LIKE* systems that take care of the common things for you.

One of the most difficult decisions I faced when building Albatross
was deciding what to make implicit and what to leave to the developer.

When you make something implicit you remove some flexibility from the
application developer.  I imagine you wondered from time to time when
building JOTWeb whether or not something should be implicit.

- Dave

-- 
http://www.object-craft.com.au