I finally had some time to look at this some more. I think this is a
good start, and I wish that something like this were available so
that I could use it for writing database-backed OpenLaszlo applications.
I had some comments about the structure of the proposal, and some
about the content.
Structure:
This is really two proposals:
- An XML syntax for declaring database-backed models and connecting
this to server-side code . This is the "Creating Models" and
"Callbacks" part of the proposal, and part of "Security".
- A REST protocol for generic CRUD. ("Generic in the sense that it
can parameterized to a specific model, such as a contacts table or a
products table.) This can be supported independently of the way that
the models are defined. This is the section "Interacting with Models".
I would like to see these separated into the two separate proposals:
one for declaring the model on the server, and one for interacting
with it on the client. I believe that the second is more broadly
applicable. The first overlaps with the capabilities of Fowler-based
frameworks such as Rails, RIFE, CakePHP, JavaScript Junction. It
could easily be built using those frameworks, but a developer might
choose to implement the model directly in those frameworks, instead
of in XML that code using the frameworks interprets.
The REST protocol, on the other hand, would be useful for any use of
OpenLaszlo with any server-side model. Standardizing on it will have
three benefits:
- It absolves the developer of the need to design a client/server
protocol. Having a debugged design is an immediate advantage, even
if the development team needs to implement both sides of the protocol.
- It allows the development of library extensions to MVC frameworks,
so that a development team need only implement the Model, and not the
client/server communication. The original proposal called for the
development of such an extension for PHP, to support the XML syntax
in the first part of this proposal. Defining the REST protocol as a
separate standard allows users of other frameworks to write libraries
for these other frameworks. For example, a "laszlo_scaffold" Rails
macro could define a set of methods that implement this protocol by
serving the XML files in the specification, in the same way that the
"scaffold" macro defines a default set of URL handlers for serving
HTML that is targeted at human agents.
- It fosters the development of client-side components that operate
with this protocol. For example, I would hope to see OpenLaszlo
components that could be parameterized with a model's base URL in
order to create a sortable paging list or tree view that optionally
supported edit and delete, a detail view of a single record, an edit
view of a single record, or a master detail view that composed these
components --- in much the same way that the existing tree and grid
control can be easily wired to an XML datasource.
On to the REST protocol. There are two parts to this, too, that
differ in the way information is requested from the client:
- A URL-based REST protocol for generic CRUD. This can be supported
independently of the way that the models are defined. This is the
URL syntax portion, and the entire semantics, of "Interacting with
Models".
- Ann XML-based protocol for generic CRUD. (This is XML-based in
that the server operation or query is encoded in the XML content of a
request. Both protocols use XML as the response.) This too can be
supported independently of the way that the models are defined. This
is the Tag syntax portion, and the entire semantics, of "Interacting
with Models".
I question the need for both of these. It will simplify development
to focus on one. Is there any difference in the features that they
provide?
Content:
* /schema and /contact/schema should return
<record name="contact">...
instead of
<contact>...
This will make it possible to validate them; also it will be easier
to programmatically process all the records in a schema.
* We need to decide whether types refer to the database, or to the
model. Currently the refer to the model, e.g. "varchar". A
JavaScript or XML name such as "String" is probably more appropriate,
since part of the role of the ORM is to abstract the database
implementation. More specifically, it is going to be a bother to
write client code that tests for varchar|tinytext|text|bigtext, and
the standard ORMs already have code that does this.
* The default method returns fields as attributes. This isn't
practical for longer fields, which would need to be returned as the
content of child elements. The specification does make it possible
to write a custom method that returns arbitrary XML, but since this
is such a common case, the spec should specify a convention for the
schema for this case, even if it doesn't specify the method that the
server-side developer uses to force field values into children
instead of attributes. For example:
<contact first_name="Max" id="1">
<!-- associations and aggregations .... -->
<field name="affadavit">I have known Max for four years <!--
thousands more characters of textual content --> darn good spec.</
field>
</contact>
(The spec says that the default index method returns "any related
data listed as subnodes". I assume it means "any aggregations and
associations". Also "child elements" is more technically correct
that "subnodes" here.)
* Just punt on BLOBs for now? I don't imagine that they'd be
terribly useful; it's easy enough to add them later if there's a
compelling use case.
* Feeping creaturism: It would be nice to have a convention for
referencing an image that is stored in a database column (or in a
pair, for data and MIME type). That's actually the only realistic
use of BLOBs I can imagine, and it needs to be handled on the server
anyway, since the client can't realistically parse the BLOB out of
XML and do anything useful with it.
And on the URL mapping:
* Using /contact/schema instead of /schema/contact would simplify the
server implementation. It also slightly simplifies the construction
of a generic client component that is connected to a model, because
all of its URLs look like baseurl + command, where baseurl includes
the component name.
* Using /contact/command?page=1 instead of /contact/1?command=page,
etc., is a better match for the Rails-based frameworks.
Lastly, Bruce Peren's "model based security" (sorry, but I'm writing
offline so I don't have a URL) is probably a pretty good reference
for how to secure against an insecure controller and view. (In the
use of an OpenLaszlo application with a server component that
implements this proposal, the server's controller is essentially
insecure, as it's operating as a pass-through for commands coming
over HTTP from an unsecured node.) It has that advantages that it is
already specified, that it's available as a plug-in for Rails, and
that (for these two reasons) something like this is more likely to be
implemented for other frameworks such as CakePHP if we don't
implement it as part of this project, or to be adopted and supported
if we do.
Again, this is a great start, and I look forward to using it.
Best,
Oliver
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
