[Laszlo-dev] Re: Laszlo-dev Digest, Vol 13, Issue 14

[Pete Farmer]

Dear Max,

I'm a long-time lurker, but first-time poster to this list, and
reviewing your spec with great interest as it hammers on several of my
immeadiate priorities.

I'm currently working on a project where the software stack looks
roughly like this:
MySQL + JDBC + Tomcat + Cocoon + OpenLaszlo

The data model is now sufficiently complex to require a persistence
layer, so I've spent the last week experimenting with three different
approaches: Hibernate 3.0, OJB-JDO, and Cocoon's (deprecated) Modular
Database Actions.

Of the three, I'm currently leaning toward Hibernate, and although
I've found the learning curve quite steep, I have a lot appreciation
for the elegance and _power_ of this great opensource project.

The Cocoon Modular Database Actions were easy to get working quickly,
but everything I've been able to read about them suggests finding
another solution as they have been deprecated in favour of a Hibernate
or OJB approach.

OJB-JDO is slated as today's struggle -- wish me luck, thanks.

My initial reaction to your spec is deep gratitude. I love working
with openlaszlo, since as a 'server programmer' I rarely get the
chance to write and software with a GUI interface. OpenLaszlo gives me
the chance to write programs which users will actually /see/ on the
screen. This is a big novelty for me, since for years, (since
NeXTStep) my only 'users' have been other developers.

However, your spec raises the following questions:

How much practical application will this feature have in a stack
similar to the one I've described, where openlaszlo is being used
purely as the presentation layer, or 'View' in an MVC architecture?

Currently, my 'Controller' is the Cocoon sitemap.xmap + server-side
ECMAscript (called 'flowscript' in Cocoon) + XSPs (essentially JSPs
for this discussion). In order to take advantage of the features
described by your spec implies that I would be moving some Controller
functionality from server-side to client-side, if I understand things
correctly. Is this correct?

More accurately, (or modernly), I would like to describe my
architecture as an SOA, where OpenLaszlo, as the presentation layer,
simply calls REST-ful services, and does very little else, other than
render beautiful widgets.

Forgive me if I've misunderstood something here, I'm a bit old-school
with a lot of this stuff, and still have trouble keeping track of
execution space in these new-fangled web applications. :-)

Now, on to some specifics in your spec:
1. Relationship Mappings
The spec describes one-to-one, one-to-many, many-to-many, and
belongs-to. Are these all bi-directional? I ask this because the
Hibernate docs describe these same mappings, but they vary depending
on whether the mapping is intended to be uni- or bi-directional. Would
you please be so kind as to explain this when you have time?

n. Protecting against SQL injection attacks?
What protection does escaping SQL strings offer from this type of
attack? Why couldn't an attacker just escape /their/ SQL strings and
subvert this mechanism? I'm confused.

n. Do this spec intend to support db Transactions and Rollbacks?
I think that my requirements, and what would draw me toward using a
persistence layer are probably similar to many developers. I want to
read from and write to multiple tables, via a bean or POJO, while
retaining some fine-grained control just in case the read or more
likely the write is unsuccessful.

I guess my overarching concern with the spec is that of moving
processing from server-side to client-side. I'm wrong about this,
right? I thought so... ;-)

Thank you again for making such a wonderful product, and so generously
providing it to the open source community.

best,
--p










On 10/21/05, laszlo-dev-request at openlaszlo.org
<laszlo-dev-request at openlaszlo.org> wrote:
> Send Laszlo-dev mailing list submissions to
>         laszlo-dev at openlaszlo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> or, via email, send a message with subject or body 'help' to
>         laszlo-dev-request at openlaszlo.org
>
> You can reach the person managing the list at
>         laszlo-dev-owner at openlaszlo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Laszlo-dev digest..."
>
>
> Today's Topics:
>
>    1. For your review: Laszlo Database API spec (Max Carlson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Oct 2005 22:56:39 -0700
> From: Max Carlson <max at laszlosystems.com>
> Subject: [Laszlo-dev] For your review: Laszlo Database API spec
> To: OpenLaszlo development and bug reporting
>         <laszlo-dev at openlaszlo.org>,    laszlo-on-rails at googlegroups.com
> Message-ID: <43588317.6010808 at laszlosystems.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'd like your feedback on the attached spec.  The notion is to have a
> common REST API for Laszlo to read form and communicate changes to
> remote data sources.  The plan is to create a special Laszlo dataset
> that knows how to speak this protocol and can automatically sync with
> the back-end.  The first implementation will likely be in PHP and
> support SQL databases such as MySQL.  Later implementations could be
> built on other platforms - I'd love to see one built on Rails.  It's
> important to note that the protocol is designed to be general enough to
> work with any data source that has sets of records - it's not
> necessarily tied to SQL databases.  I look forward to hearing your
> thoughts and feedback!
>
> Regards,
> Max Carlson
> OpenLaszlo
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: database connector spec 101005.pdf
> Type: application/pdf
> Size: 214278 bytes
> Desc: not available
> Url : http://openlaszlo.org/pipermail/laszlo-dev/attachments/20051020/0ca2b25b/databaseconnectorspec101005.pdf
>
> ------------------------------
>
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
>
> End of Laszlo-dev Digest, Vol 13, Issue 14
> ******************************************
>