[Laszlo-dev] For your review: Laszlo Database API spec

[phuduc nguyen]

Oooooooooooh, my apologies for reading the spec
incorrectly...I suck.

cheers,
Duc





--- Max Carlson <max at laszlosystems.com> wrote:

> Hi Duc,
> 
> Thanks for your response.  I've replied below.  Once
> again, let me know 
> how I do!
> 
> phuduc nguyen wrote:
> > Hi Max,
> > 
> > I wanted to let this brew for a few days so I
> could
> > respond with some thought put into this. I was
> > concerned that my response would be too influenced
> by
> > mere tradition, i.e., what I'm accustomed to with
> > regards to design and code. But after a few days,
> I
> > think I still hold the same opinion. Comments
> below...
> > 
> > 
> >>Since Laszlo applications are stateful, it's
> >>possible to put most of the
> >>controller in the OpenLaszlo application.  For
> >>example, a shopping cart
> >>can be entirely maintained on the client, only
> >>requiring a connection to
> >>the server for checkout and credit-card validation
> >>steps.  This blurs
> >>the separation between model and controller.
> > 
> > 
> > This is where I'm a little hesitant. I agree with
> the
> > client being stateful. What I don't agree with is
> the
> > client taking any action based on it's state.
> Other
> > components on the server side should be
> responsible
> > for acting on the client based on it's state; this
> > would encompass the entire business logic layer. 
> 
> Of course, Laszlo gives you the flexibility to work
> this way.  What I 
> meant to say is, Laszlo provides flexibility that
> allows developers to 
> blur the model and controller as much or as little
> as they like.
> 
> > 
> > 
> >>To contrast with this approach, the database API
> >>does not execute SQL
> >>directly.  All SQL queries are generated by the
> >>server, based on
> >>abstract method calls and commands sent from the
> >>client.  The server API
> >>provides access control and hooks for business
> logic
> >>such as validation.
> >>  This is very different from talking directly to
> >>the database, and as 
> >>such provides a clean separation.
> > 
> > 
> > I almost agree with you here. If it were truly a
> thin
> > and abstract layer that is generated from the
> client,
> > then yes I would agree and jump on this proposal
> > offering any help possible. However, reading the
> spec
> > again, I still feel like there's a little too much
> > knowledge of the backend inside the client API. It
> > doesn't really feel that thin and abstract. For
> > instance, your model tag has an attribute name
> that
> > directly maps to the DB tablename: 
> > <model name="tableName">...</model>. You say
> there's
> > another server side layer that actually executes
> the
> > SQL to the DB, even so, doesn't that mapping blur
> the
> > lines a bit too much? So another server side layer
> > could hold the actual DB connections and handle
> > pooling; however, other attributes in your API
> address
> > very specific DB logic like joins, order, foreign
> key,
> > commits, and rollback. Or have I read the spec
> wrong?
> > If so, I sincerely apologize for wasting eveyone's
> > time. Just my 2 pennies...
> 
> Sorry, I should have been more clear.  The model
> definition XML you 
> refer to actually resides on the server.  The client
> to request a copy 
> so to introspect allowed methods, but the client
> can't actually specify 
> anything database-related.  Clients are only allowed
> to call predefined 
> methods.
> 
> Regards,
> Max Carlson
> OpenLaszlo
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com