Re: web application framework
From: Will Hartung (willh_at_msoft.com)
Date: 11/12/03
- Next message: Bill Clementson: "Denver Area Lisp Users Group meeting #6"
- Previous message: Frank A. Adrian: "Re: How to put together a home computer with GNU/Linux"
- In reply to: Adrian Kubala: "Re: web application framework"
- Next in thread: Vladimir S.: "Re: web application framework"
- Reply: Vladimir S.: "Re: web application framework"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 12 Nov 2003 11:20:07 -0800
"Adrian Kubala" <adrian@sixfingeredman.net> wrote in message
news:Pine.LNX.4.56.0311112002060.20431@sixfingeredman.net...
> On Mon, 10 Nov 2003, Will Hartung wrote:
> > Most app/form generators that I've seen (albeit, most of them have been
> > for simple DB screens, not web pages) are utter crap. They happily spit
> > out Kbytes of boiler plate template code that is only a fraction above
> > cutting and pasting in terms of sophistication. [...]
>
> That's why I'm hoping Lisp will be a cut above -- it has a built-in
> preprocessor (macros) so your "boiler plate" automatically gets generated
> every time you compile.
Actually the macros will shroud the details, but the problem remains. Since
the macro encapsulates logic, if that logic doesn't "do what you want", then
all of a sudden the macro is basically worthless. The side effect is that
the higher level the macro (i.e. the more funcionality it conceals), the
more work you have to do should you choose to work around it. Whether its a
macro or a function is pretty irrelevant (though you can cheat and
macroexpand the macro to "steal" its output and hack it directly, that's
difficult to do with a function).
So, granularity is very important.
>
> > [...] Using a mechanism much like "within the after change in name field
> > block, replace the block of text delimited by these two regexps with
> > ....".
>
> Sounds like primitive, fragile, unstructured macros to me.
More like an automatic patching system. Rather than writing source code,
you're essentially writing patches to the generated code. It does sound
crude, and in many ways is, but since the generated code is well structured
it's not as painful as it sounds.
> > I thought about a similar system leveraging CL macros, but having
> > database dependent macros didn't sit right with me. [...]
>
> Database-dependent... I take it you mean that it infers the data model
> from the database? I was envisioning more having the macro-defined data
> model be authoritative, and teach it to output database schemas or schema
> deltas to keep the database up-to-date manually.
Perhaps data-model dependent is a better word, but it turns out that SQL
databases are fabulous places to store data models of relational databases.
You always have synchronization issues no matter what (whether between you
model and you database, or you development DB and the production DBs).
> > Today, I think a combination of a solid "boiler plate" class core that
is
> > designed to be overloaded/pre-empted combined with reflection and a high
> > level definition file would be a pretty good solution.
>
> Well, I'm still very fuzzy on how an ideal system would work (or I'd be
> working on it instead of babbling here) but I have some vague ideas about
> approaches I think won't be able to go far enough. For example, any
> traditional OO-relational mapping, because it cripples your ability to use
> arbitrary relations flexibly. And like you said, I don't think inheritance
> will be able to handle all customizations, but modifying the base class is
> not an option I'd like to consider. I have a gut feeling that generic
> functions, HOFs, units/functors/mixins and code-walking macros would all
> be part of the ultimate solution.
I have a gut feeling that you're overcomplicating things, but I'm basically
lazy.
I'm partial to a fine grained object model with a generated core mostly
because it, in the end, exposes all of the functionality to you in a form
where you can actually do something to change the behavior: source code.
Your application (or application component as in "Customer Maintenance" vs
"E-Commerce Suite") is broken in to the three components. The common core
shared by all similar components, the schema centric generated scut code,
and the specializations that make the default app work the way you want.
As long as your app modules follow all of the assumptions of the framework,
everything is easy. But many times, you'll find that your app needs to
"bend" the model a little bit.
If that model is rigid, it doesn't bend at all and you get to throw the
whole thing out for minor deviations. When the model is exposed as higher
level macros and functions, it can actually be quite rigid. Same problem
with a reflection based system, because a lot of the internal mechanism of
the application is actually hidden by automated processes relying on meta
data. And if that meta data doesn't convey some detail that you find
imporant for a specific case, blammo, out goes the introspection and
reflection. If that bit is actually critical to what you need to do, say for
one particular field of the table, then not only did you lose the automation
for that one field, you lost it for the entire table. The goal is not to
have to adapt the core engine to the variances of your application. If the
core engine is completely off base, then sure, changes may be justified.
However, say for example you have 50 simple database tables that need to be
maintained, but 1 of them is actually two tables combined (and you, say,
don't have an updateable view on your DB which may solve that problem
elegantly). It can be argued that the core system designed to make creating
maintenance programs for single tables is flawed because it can't handle
this "two table" solution. A lot of folks would have to lose the tool
completely because of this, or complicate that system to handle the rare two
table case (and, no doubt, probably punish the other 49 single table
examples to handle the new more general case).
But if you can take ownership of a couple of core pieces of the engine for
this case, then you have one minorly tweaked black sheep program in the sea
of 50 that can still leverage the system in other ways.
A fine grained model will give you that flexibility, specializing the bits
that need it. It also gives the more advanced APPLICATION programmers that
power without them having to rewrite core macros or tweak code walkers. They
just need a solid understanding of the model.
So, automation is good, source code is better, but automatic source code is
the best.
This doesn't eliminate the need for functions and macros to implement low
level parts of the engine, things that simply should not be changed for the
sake of an application, but the goal is to have something that lets the app
writers leverage the tool, bend it as much as possible and have to punt on
only the real fringe of the domain.
Let the users throw away small parts of the engine and tool, rather than
make them throw it away entirely.
It's a fine balance, because flexibility comes at a cost in complexity, and
the whole point is to make the process as simple as practical.
Regards,
Will Hartung
(willh@msoft.com)
- Next message: Bill Clementson: "Denver Area Lisp Users Group meeting #6"
- Previous message: Frank A. Adrian: "Re: How to put together a home computer with GNU/Linux"
- In reply to: Adrian Kubala: "Re: web application framework"
- Next in thread: Vladimir S.: "Re: web application framework"
- Reply: Vladimir S.: "Re: web application framework"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
