Re: separating C from V in MVC

[Perrin Harkins]

Tony Bowden wrote:
> I'd have to disagree. Maybe Mike had something different in mind when he
> created Class::DBI, but as the current active developer on it, I'm
> definitely pushing it in the R-O direction. Like Dave, I always start by
> thinking of my database schema and then Class::DBI provides a way to
> translate that, table -> class, row -> object, column -> method. Throw
> in some simple relationship builders and a sprinking of syntactic sugar,
> and that's pretty much there is to Class::DBI.

Tangram may have loftier goals, but in general that's pretty much all 
there is to any of them.  And I don't think that the angle you approach 
your data design from -- classes or tables -- has much bearing on which 
tool you would use, with the possible exception of Tangram.  SPOPS is 
explicit about wanting to support legacy schemas without changes.

I think that in this realm there is Tangram, which tries to bring some 
extra stuff like database modelling of object inheritance and queries 
written in perl, and everything else.

>>Things like Tangram model the domain objects, i.e. concerts,
>>seats, people.  Things like Alzabo model the database objects, i.e.
>>tables, rows, foreign keys.
>  
> I think on this front they both try to do both. Class::DBI does anyway.

My casual perusal of the documentation certainly made it look like 
Class::DBI hid a lot more of the database stuff than Alzabo.  After the 
configuration is done, the database concepts like foreign keys are never 
explict.

I guess my point here is simply that I think there isn't so much 
difference between most of these tools and that characterizing them as 
being anti-database or too heavy is not accurate.

As a sort of wrap-up to this round of O/R technology discussion, I want 
to post a link to this quote from the author of SPOPS where he talks 
about the practical limitations of SQL abstraction.  I thought it was a 
pretty astute observation:
http://perlmonks.org/index.pl?node_id=162259

- Perrin

Re: separating C from V in MVC

[Tony Bowden]

[sorry for the broken References - I've just joined the list and am
replying to a post in the archives]

On Sat, 15 Jun 2002, Perrin Harkins said:
>> An Object-Relational mapper takes objects and stores them in a relational
>> database, as transparently as possible.  I think the most pure example of
>> this I've seen in the Perl world is Tangram (www.tangram-persistence.org).
>> SPOPS is also an O-R mapper (actually, its a generic Object persistence
>> mechanism but it seems to most feature-rich when used with an RDBMS).
>> A Relational-Object takes a relational database, and provides access to it
>> (select, insert, update, delete) via objects.  Class::DBI, Alzabo, and
>> DBIx::RecordSet are examples of such a beast.

> I would actually put Class::DBI in with the first set.

I'd have to disagree. Maybe Mike had something different in mind when he
created Class::DBI, but as the current active developer on it, I'm
definitely pushing it in the R-O direction. Like Dave, I always start by
thinking of my database schema and then Class::DBI provides a way to
translate that, table -> class, row -> object, column -> method. Throw
in some simple relationship builders and a sprinking of syntactic sugar,
and that's pretty much there is to Class::DBI.

> To me the difference is not O/R vs R/O, since both of them go both
> directions.  Rather it's a question of what you're modelling in your
> objects. 

I think one of the main differences is in what ways you want to be able
to manipulate your data. With an R/O approach the Perl classes are just
one of the possible views into your data. If you feel like it you can
also do your normal SQL type things on it. In fact one of the deliberate
strengths of Class::DBI is that you can very easily port an existing
"roll-your-own-SQL-in-Perl" approach over to it gradually. With O/R
approaches the object is usually the primary source of the data and the
database is just a temporary storage system used for persistence. You
probably _could_ go executing arbitrary commands against the database,
but it's frowned upon.

> Things like Tangram model the domain objects, i.e. concerts,
> seats, people.  Things like Alzabo model the database objects, i.e.
> tables, rows, foreign keys.

I think on this front they both try to do both. Class::DBI does anyway.
It assumes that you're going to create your database schema in a way
that these are fairly much interchangable.

Tony

Re: [OT] WebObjects [Was: Re: separating C from V in MVC]

[Perrin Harkins]

> Not quite sure what you mean here.  The general WO request-response
loop is
> 1 Process request
> 2 Perform action
> 3 Return response
>
> Step 3 is entirely dependent on the previous two, just like any
> mod_perl/CGI/php app.

The introductory documentation makes it look each URL is tied to a
specific HTML template.  It may just be a problem with that
documentation though.

> I think the most perfect web
> development env would be a WO-style framework build on top of mod_perl

You can assemble various parts of it from CPAN.  Most of the perl O/R
frameworks are not as ambitious as EOF, but Tangram is trying pretty
hard.  The templating tools available for perl are as good as the ones
in WO.  Using those with one of the MVC frameworks discussed here gets
you quite a bit.  The main thing you don't get is GUI tools, which there
doesn't seem to be much demand for from the mod_perl community.

- Perrin

Re: [OT] WebObjects [Was: Re: separating C from V in MVC]

[Kyle Dawkins]

Perrin &al

> > Once you use it, everything else
> > sucks.  There are no exceptions.
> That's kind of a rude statement to make on this list, where all of these
> people are offering free software and support to you.

Ah, you're right; I actually never meant that as a slight against things
mod_perl; I use mod_perl and I support it fervently.  But mod_perl & WO are
at two different places in the stack; WO is a rich framework, mod_perl is an
all-powerful skeleton on which we *build* our frameworks.

> It's been a few years since I last evaluated WebObjects, but it
> certainly didn't seem like a panacea.  It had a number of interesing
> ideas behind it, but its insistence on trying to hide all the details of
> the browser interaction made some simple things very hard, especially
> since it tried to keep all of the state information server-side.  The
> problems it had with back buttons and multiple browser windows come to
> mind

Might have been a problem a long time ago but it's certainly not now. WO
supports both its own kind of steroid-enhanced session tracking, which does
create problems with back-buttons if you don't use it properly, but it also
supports regular mod_perl-style request/response cycles that are perfectly
fine with back-button/multiple-window/bookmarking tasks.

> It also seems to encourage design where browsers directly request
> a view, rather than calling a controller which chooses a view depending
> on the outcome of processing.  That could be just a shortcoming of their
> introductory documentation though.

Not quite sure what you mean here.  The general WO request-response loop is
1 Process request
2 Perform action
3 Return response

Step 3 is entirely dependent on the previous two, just like any
mod_perl/CGI/php app.

WO completely forces division of your C & your V and gives you a huge hand
in separating your M from either of those.

Anyway, sorry if anyone was slighted; I think the most perfect web
development env would be a WO-style framework build on top of mod_perl
(because who wants to use Java? Jeez)

Cheers

Kyle Dawkins
Central Park Software

Re: separating C from V in MVC

[Perrin Harkins]

> An Object-Relational mapper takes objects and stores them in a
relational
> database, as transparently as possible.  I think the most pure example
of
> this I've seen in the Perl world is Tangram
(www.tangram-persistence.org).
> SPOPS is also an O-R mapper (actually, its a generic Object
persistence
> mechanism but it seems to most feature-rich when used with an RDBMS).
>
> A Relational-Object takes a relational database, and provides access
to it
> (select, insert, update, delete) via objects.  Class::DBI, Alzabo, and
> DBIx::RecordSet are examples of such a beast.

I would actually put Class::DBI in with the first set.

To me the difference is not O/R vs R/O, since both of them go both
directions.  Rather it's a question of what you're modelling in your
objects.  Things like Tangram model the domain objects, i.e. concerts,
seats, people.  Things like Alzabo model the database objects, i.e.
tables, rows, foreign keys.

My approach falls in the first camp, although I don't currently use any
OOP tools for assistance.

- Perrin

Re: separating C from V in MVC

[Perrin Harkins]

> This approach works for some things, but I think it falls down when it
> comes to doing complex database searches, particularly searches
generated
> ad-hoc on multiple columns in multiple tables.

In general, the user interface you provide for a search will be much
higher-level than the SQL that implements it.  That's what is gained by
making this kind of object: it's a place to put the translation of the
business concept "find people in New Jersey" into the four table join
that might be needed to find them.

> This is why Alzabo is much lower-level than what you have above.  I
needed
> something where I could easily construct queries that might include 1+
> tables, with various types of searches of individual columns in those
> tables (equal to, between, less than, like, etc.) with dynamic sorting
> (again, on any of the columns in any of the tables, ascending or
> descending).

I would just write SQL at that point, but I do realize that Alzabo
provides more database independence.  You could easilly use Alzabo to
build the queries that implement the model objects I'm talking about.

> With what you're proposing, I think you could easily end up with
either:
>
> A) a ridiculously flexible interface that looks sort of like SQL,
except
> where it is SQL, except where it's only sort of like SQL, etc.
>
> B) a ridiculous profusion of classes, methods, or both.

I think you're overestimating the number of search variations and model
objects that most applications have.  For example, Fran's application
generates his "stale watches report".  There's no need to create a
fully-parameterized search interface to Watch objects just for that.
Instead, you make a Watches->find_stale() method or something and keep
the knowledge of what that means to the database hidden behind that API.

At eToys we had a very large and complex (highly normalized) database,
and this approach worked very well.  I think it works best when you have
a complex database requiring complex SQL, because if you just have a
bunch of simple 1-1 table mappings there isn't really much to abstract.

I'm thinking of trying out SPOPS the next time I do this kind of thing,
because it will automatically handle the no-brainer cases (1-1 mappings)
and allow me to write the SQL for the complex cases by hand, all with a
consistent interface and hooks for caching, etc.

> Trying to jam a thick layer of OO-goodness over relational data is
asking
> for a mess.  OO has its place, but if your application is primarily
about
> the database, I don't think that a heavy OO layer on top of that will
do
> you much good.

There's nothing "thick" or "heavy" about the way I do it.  There is no
automatic SQL generation, and nothing to prevent me from using any SQL
tricks that my database supports.  It's just a way of wrapping up chunks
of code that implement data-related tasks into an easy task-oriented API
for the controller (or other model objects) to act on.

- Perrin

Re: separating C from V in MVC

[Perrin Harkins]

> My general motto is "tiers eq tears" ... I've never seen
> a really comfortable OO/SQL bridge.

So who's talking about an OO/SQL bridge?  Not me.  At least not an
automatic one.  I write the SQL by hand.

> Group bys, order bys, multi-table selects, locking, SQL query
> plans and index optimisation all rightfully belong to the database but
are
> an anathema to a simple OO/SQL bridge.

I use all of those things in my model objects.  The model objects use
SQL to implement methods like $product->user_comments() or
$address->save(), and sometimes it is complex.  The point is that the
rest of the application gets to the database through the model objects,
rather than through SQL.  Encapsulation, reuse, blah blah blah.

> Generally I try to minimise the layers/tiers/abstraction between
> the front-end and the database - for me OO/SQL abstraction is
something
> akin to 'GOTO considered harmful'.

I think you're overgeneralizing based on some kind of O/R mapping tool
you've used that tried to do too much.  Wrapping up the knowledge of how
to work with the database to accomplish certain tasks inside of objects
is no different from any other application of OO programming.

- Perrin

Re: [OT] WebObjects [Was: Re: separating C from V in MVC]

[Perrin Harkins]

> WO is amazing, no two ways about it.  Once you use it, everything else
> sucks.  There are no exceptions.

That's kind of a rude statement to make on this list, where all of these
people are offering free software and support to you.

It's been a few years since I last evaluated WebObjects, but it
certainly didn't seem like a panacea.  It had a number of interesing
ideas behind it, but its insistence on trying to hide all the details of
the browser interaction made some simple things very hard, especially
since it tried to keep all of the state information server-side.  The
problems it had with back buttons and multiple browser windows come to
mind.  It also seems to encourage design where browsers directly request
a view, rather than calling a controller which chooses a view depending
on the outcome of processing.  That could be just a shortcoming of their
introductory documentation though.

- Perrin

Re: separating C from V in MVC

[Drew Taylor]

Fran,

I think the key here is taking care of the 80% easily. This has been 
mentioned in this thread several times, and in previous threads. No, I 
don't think there will ever be an (efficient) wrapper that can handle ALL 
the cases and ALL the possible SQL queries. But if you can handle the 
majority of them easily with a wrapper, and that wrapper also provides a 
way to get at the SQL directly (I heard SPOPS as being good for this), then 
that is a lot of work saved. Work saved = money & time saved = you look 
better to your boss.

Both approaches have merit, so the trick is to determine which one is best 
for your situation. At my day job, the tables are relatively denormalized, 
ie. very wide, so a wrapper can easily work. At a previous job I was 
working to encapsulate all the SQL calls into a single module. The ability 
to find the approach that works best for you is the difference between a 
grunt and a good software engineer. :-)

Drew

At 01:30 AM 6/14/02 -0400, Fran Fabrizio wrote:

>I don't typically find apps that just mirror some subset of one of the db 
>tables to be all that interesting.  After all, it's the relationships 
>between the data that make the data interesting, and by necessity this 
>means your queries will be complex.  And looking over the stuff outlined 
>at poop.sourceforge.net, there's not too many models/frameworks out there 
>that can accurately abstract ALL of SQL, and if it only does a subset, I 
>feel like that's shooting myself in the foot.

==
Drew Taylor  |  Freelance web development using
http://www.drewtaylor.com/   |  perl/mod_perl/MySQL/postgresql/DBI
mailto:[EMAIL PROTECTED]   |  Email jobs at drewtaylor.com
--
Speakeasy.net: A DSL provider with a clue. Sign up today.
http://www.speakeasy.net/refer/29655
==

Re: separating C from V in MVC

[Dave Rolsky]

On Fri, 14 Jun 2002, kyle dawkins wrote:

> bigger system, but I would also caution people to say that if you find
> yourself doing joins across up to 6 tables, you're almost certainly
> doing something wrong from the start and, basically, you're fooked
> because of shitty design, and O/R or R/O won't help you.

This is one of the sillier statements I've seen on this list.

If you have complex data with many entities (and thus many tables) and you
have complex queries then you can easily find yourself joining many
tables.

This is hardly a sign of bad design.  In fact, it may be a sign of good
(normalized) design.

If _all_ of your queries are against 1 table at a time, that seems a lot
more worrisome to me (because it suggests insufficient or non-existent
normalization).


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: [OT] WebObjects [Was: Re: separating C from V in MVC]

[kyle dawkins]

Drew is correct, EOF stands for "Enterprise Object Framework".   
However, it's not "part of" the WebObjects app server... it predates WO 
by a long time (I think it's about 9 or 10 years old) happens to come 
with WO but is completely separate from it.

On Friday 14 June 2002 11:27, Drew Taylor wrote:
> For those of you (like me) who didn't know what EOF is, it stands for
> Enterprise Object Framework and is part of Apple's WebObjects app
> server. Which has moved on to Java, and thus is OT. :-) But I've
> heard many good things about WebObjects, so it's on my wish list of
> technologies to investigate.

WO is amazing, no two ways about it.  Once you use it, everything else 
sucks.  There are no exceptions.

Kyle Dawkins
Central Park Software

[OT] WebObjects [Was: Re: separating C from V in MVC]

[Drew Taylor]

At 10:59 AM 6/14/02 -0400, kyle dawkins wrote:

>As for people claiming never to have seen an OR system that works, I
>suggest you check out EOF from NeXT/Apple.

For those of you (like me) who didn't know what EOF is, it stands for 
Enterprise Object Framework and is part of Apple's WebObjects app server. 
Which has moved on to Java, and thus is OT. :-) But I've heard many good 
things about WebObjects, so it's on my wish list of technologies to 
investigate.

Drew

==
Drew Taylor  |  Freelance web development using
http://www.drewtaylor.com/   |  perl/mod_perl/MySQL/postgresql/DBI
mailto:[EMAIL PROTECTED]   |  Email jobs at drewtaylor.com
--
Speakeasy.net: A DSL provider with a clue. Sign up today.
http://www.speakeasy.net/refer/29655
==

Re: separating C from V in MVC

[kyle dawkins]

> The Pet Shop has a grand total of 13 tables.
>
> How well does this approach work with 90 tables?  How does it handle
> arbitrary queries that may join 1-6 tables, with conditionals and
> sorting of arbitrary complexity?

Where I work we have over 90 tables and it works fine.  We don't run a 
ticketing system or a huge e-commerce site but our servers are pretty 
busy and we have no performance problems.  Our application layer does 
not contain a single line of SQL.  The entire system is OO Perl and 
uses an OR-mapping system that entirely abstracts the tables and 
relationships between them.  It works for us.  Maybe it wouldn't for a 
bigger system, but I would also caution people to say that if you find 
yourself doing joins across up to 6 tables, you're almost certainly 
doing something wrong from the start and, basically, you're fooked 
because of shitty design, and O/R or R/O won't help you.

> > We've found the O/R mapping to be an indispensable part of the
> > system.  Since all data is contained in objects, the views/widgets
> > don't need to how the data is populated.  They access all data
> > through a single interface.

This is how our system works too.  Less code, fewer bugs (we hope!), 
faster development time.  For us it's awesome; your mileage may vary.

As for people claiming never to have seen an OR system that works, I 
suggest you check out EOF from NeXT/Apple.  That puppy runs banks and 
insurance companies, and usually without needing a line of SQL.  It's 
not perfect, but it's pretty friggin amazing.

Each to his/her own.

Kyle Dawkins
Central Park Software

O-R mapping vs. R-O mapping (was Re: separating C from V in MVC)

[Ray Zimmerman]

At 12:22 AM -0500 6/14/02, Dave Rolsky wrote:
>An Object-Relational mapper takes objects and stores them in a relational
>database, as transparently as possible.  I think the most pure example of
>this I've seen in the Perl world is Tangram (www.tangram-persistence.org).
>SPOPS is also an O-R mapper (actually, its a generic Object persistence
>mechanism but it seems to most feature-rich when used with an RDBMS).
>
>A Relational-Object takes a relational database, and provides access to it
>(select, insert, update, delete) via objects.  Class::DBI, Alzabo, and
>DBIx::RecordSet are examples of such a beast.
>
>I think what it comes down to is "how do you start thinking your project?"

Well said, Dave. I don't think one approach is strictly better than 
the other. It depends what you need to accomplish. I wouldn't be 
surprised to find that the majority of the folks on the modperl list 
would favor an R-O approach to an O-R one, but that's because 
probably the vast majority of web apps are primarily about the data.

This happens to not be the case for me and I find my O-R mapper to be 
enormously helpful, exactly what I need most of the time. I'm using 
ESPOPS, a package built on top of SPOPS to handle objects with 
inherited attributes spread across multiple tables. Granted, when I 
do need to fetch my objects based on complicated criteria involving 
joining of lots of tables, it's not as clean as I'd like. It requires 
passing SQL fragments into the fetch methods.

To me this just means that my O-R mapper has abstracted things nicely 
to the point where I don't have to touch any SQL 90% of the time, but 
for those cases where I do need more complicated SQL, it lets me 
directly at the SQL and doesn't pretend that it's going to be able to 
do everything I might want. This seems like a good tradeoff to me.

One possible improvement (with emphasis on possible) might be to 
build the O-R mapper on top of something like Alzabo or some other 
R-O mapper which does a more complete job of abstracting me away from 
the actual SQL. Then when I want to pass some more explicit query 
specs through the O-R mapper it would be in "Alzabo" instead of SQL. 
My gut feeling is that the extra layer probably wouldn't be worth it.

Anyway, my main point is O-R and R-O are different tools for 
different jobs. A hammer is not better than a saw until you know 
you're trying to drive a nail as  opposed to cut wood.

BTW, this thread should probably be moved to the poop list ...

-- 
  Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: separating C from V in MVC

[Nigel Hamilton]

> > Generally I try to minimise the layers/tiers/abstraction between
> > the front-end and the database - for me OO/SQL abstraction is something
> > akin to 'GOTO considered harmful'.
>

HI Mark,

I'm not sure about a monolithic SQL factory module like the one
you describe. Generally, each SQL statement is unique so I've never been
able to find re-use benefits here. Also passing parameters to SQL Factory
methods involves another change of scope/layer which I think is not
necessary.

In our system, a programmer maintaining the system will look to
the object first and find the SQL bang in the middle - which I think has
better re-use/maintenance implications than hidden away in a back closet
that's packed full of stuff (i.e., all the SQL).

One way I minimise the layers between DB and the front-end is to
make sure all fields share the same name as in the database - someone has
already mentioned this technique.

This follows the design tenet - a unit of data should have only
one name throughout the entire system.

Perl has a great feature: 'slippery typing' (as opposed to Java's
strong). This enables me to pass a database row hash -> to an object
constructor -> to a controller -> to a view.

In my case the view is typically a HTML template holding tokens of
the form: {{database-field-name}}.

For example, when a search occurs on Turbo10 the following happens:

* Engine Object   - contains SQL - returns a DBI row hash
* Hit Object  - is constructed with this DBI row hash
* BrowserMessenger Object - formats Hit in Javascript for tranmission to
browser using a Template
* Template Object - uses the same field names from the DBI row
hash to replace tokens

In this way, I try to minimise the interfaces going from the
database to the browser - and the SQL stays inside the objects that use
it.

Does anybody else want to confess to something similar? (-;


Nigel





> I think there's room for middle ground here between mapping OO directly
> to SQL and having SQL in heredocs in your code.  What we tend to use is a
> object that works almost as a SQL factory.  We never have SQL directly in
> our code, but rather all this is placed inside a seperate module.that
> knows a few things about itself - e,g, what database and table we're
> using for this run.  This can be then used to spit out SQL or run the
> query and return the results.
>
> The key aspect is that anytime you feel you need to write some SQL you
> should feel free to add more SQL to this module - not limit yourself to
> waht's already avalible.
>
> The advantage of this is that we get better reuse in out of our SQL when
> we need the same function called from many places, and we can reuse the
> same SQL on similar tables/databases for different runs.  Another
> advantage is that should we ever want to change the database all our SQL
> is in a few modules and we can make sure that we change all our SQL.
>
> Mark.
>
>

-- 
Nigel Hamilton
Turbo10 Metasearch Engine

email:  [EMAIL PROTECTED]
tel:+44 (0) 207 987 5460
fax:+44 (0) 207 987 5468

http://turbo10.com  Search Deeper. Browse Faster.

Re: separating C from V in MVC

[F . Xavier Noria]

On Fri, 14 Jun 2002 10:34:47 +0100 (BST)
Mark Fowler <[EMAIL PROTECTED]> wrote:

: On Fri, 14 Jun 2002, Nigel Hamilton wrote:
: 
: > Generally I try to minimise the layers/tiers/abstraction between
: > the front-end and the database - for me OO/SQL abstraction is something
: > akin to 'GOTO considered harmful'.
:
: The advantage of this is that we get better reuse in out of our SQL when
: we need the same function called from many places, and we can reuse the
: same SQL on similar tables/databases for different runs.  Another
: advantage is that should we ever want to change the database all our SQL
: is in a few modules and we can make sure that we change all our SQL.

Another useful thing is that you can implement some cache mechanism
there, in one place, and this is transparent to clients who just keep on
calling, say, $category_factory->read_category_tree(), no matter whether
the tree is actually fetched from the database or from shared memory.

-- fxn

Re: separating C from V in MVC

[Mark Fowler]

On Fri, 14 Jun 2002, Nigel Hamilton wrote:

>   Generally I try to minimise the layers/tiers/abstraction between
> the front-end and the database - for me OO/SQL abstraction is something
> akin to 'GOTO considered harmful'.

I think there's room for middle ground here between mapping OO directly 
to SQL and having SQL in heredocs in your code.  What we tend to use is a 
object that works almost as a SQL factory.  We never have SQL directly in 
our code, but rather all this is placed inside a seperate module.that 
knows a few things about itself - e,g, what database and table we're 
using for this run.  This can be then used to spit out SQL or run the 
query and return the results.

The key aspect is that anytime you feel you need to write some SQL you 
should feel free to add more SQL to this module - not limit yourself to 
waht's already avalible.

The advantage of this is that we get better reuse in out of our SQL when
we need the same function called from many places, and we can reuse the
same SQL on similar tables/databases for different runs.  Another
advantage is that should we ever want to change the database all our SQL
is in a few modules and we can make sure that we change all our SQL.

Mark.

-- 
s''  Mark Fowler London.pm   Bath.pm
 http://www.twoshortplanks.com/  [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/  +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}

Re: separating C from V in MVC

[Matt Sergeant]

On Fri, 14 Jun 2002, Nigel Hamilton wrote:

> > A) a ridiculously flexible interface that looks sort of like SQL, except
> > where it is SQL, except where it's only sort of like SQL, etc.
> >
> > B) a ridiculous profusion of classes, methods, or both.
> >
> > SQL has its place, and Alzabo merely provides a thin layer on top of it.
> >
> > Trying to jam a thick layer of OO-goodness over relational data is asking
> > for a mess.  OO has its place, but if your application is primarily about
> > the database, I don't think that a heavy OO layer on top of that will do
>
> HI Dave,
>
>   Totally agree.
>
>   My general motto is "tiers eq tears" ... I've never seen
> a really comfortable OO/SQL bridge.
>
>   The OO part almost always dumbs down or hobbles the database.
>
>   Group bys, order bys, multi-table selects, locking, SQL query
> plans and index optimisation all rightfully belong to the database but are
> an anathema to a simple OO/SQL bridge.
>
>   While disks need to seek and spin ... relational databases will
> have their place. I sometimes think of a world with unlimited RAM.  It's
> here that OO dreams really come true --- vast pools of objects with
> hash/array look up speed etc.

I feel pretty much the same, and so gave a talk about this (and other
things) at last year's perl conference. Slides are at
http://axkit.org/docs/presentations/tpc2001/anydbd.axp/a.pdf

-- 

<:->Get a smart net

Re: separating C from V in MVC

[Nigel Hamilton]

> A) a ridiculously flexible interface that looks sort of like SQL, except
> where it is SQL, except where it's only sort of like SQL, etc.
>
> B) a ridiculous profusion of classes, methods, or both.
>
> SQL has its place, and Alzabo merely provides a thin layer on top of it.
>
> Trying to jam a thick layer of OO-goodness over relational data is asking
> for a mess.  OO has its place, but if your application is primarily about
> the database, I don't think that a heavy OO layer on top of that will do

HI Dave,

Totally agree.

My general motto is "tiers eq tears" ... I've never seen
a really comfortable OO/SQL bridge.

The OO part almost always dumbs down or hobbles the database.

Group bys, order bys, multi-table selects, locking, SQL query
plans and index optimisation all rightfully belong to the database but are
an anathema to a simple OO/SQL bridge.

While disks need to seek and spin ... relational databases will
have their place. I sometimes think of a world with unlimited RAM.  It's
here that OO dreams really come true --- vast pools of objects with
hash/array look up speed etc.

Until that time though ... I personally code with the database
foremost in my mind - and disk seeks a close second - for me the SQL comes
first and so I have no problem with large 

Re: separating C from V in MVC

[Dave Rolsky]

On Fri, 14 Jun 2002, Fran Fabrizio wrote:

> >How well does this approach work with 90 tables?  How does it handle
> >arbitrary queries that may join 1-6 tables, with conditionals and sorting
> >of arbitrary complexity?
>
> I'd have to agree, most of the real-world scenarios I have run across do
> not consist of these neat 1-to-1 field to attribute type of mappings where
> the majority of the queries are simple inserts or selects from a single
> table or simple joins.  Most of the apps I work on quickly evolve to the
> point of many (in my current case, 120+) tables and where most of the
> queries are gathering data for reports/views that bring data together from
> several tables.  Joins of 5+ tables, unions, excepts, subselects,
> self-joins, complex sorting/grouping rules, etc are all commonplace and
> this is where I think overzealous attempts to abstract the queries away
> fall apart.  I guess I'm more of the Perrin school of thought, where I
> prefer crafting all the SQL directly.

I never said I like to actually write SQL directly.  See below ...

> I don't typically find apps that just mirror some subset of one of the db
> tables to be all that interesting.  After all, it's the relationships
> between the data that make the data interesting, and by necessity this
> means your queries will be complex.  And looking over the stuff outlined at
> poop.sourceforge.net, there's not too many models/frameworks out there that
> can accurately abstract ALL of SQL, and if it only does a subset, I feel
> like that's shooting myself in the foot.

Well, I'm the author of both that doc _and_ Alzabo, which of the R-O tools
described in that document supports the most of SQL except for
DBIx::RecordSet, which is quite a bit lower-level, but basically can be
used for _any_ SQL (I think).

Alzabo supports enough for me and my 90-table database.  So far I haven't
needed unions, excepts, or difference, nor have I needed subselects
(Alzabo actually has some support for subselects, though not the first
three).

I do need complex joins, self-joins, joins with aliases, complex sorting &
grouping (though it doesn't support HAVING yet), outer joins, and all
conditionals.  Alzabo does support all of this, and frankly I find it
easier to do this, particularly when it needs to be done on the fly, then
I could by just generating SQL in the app itself.

I'm all for _some_ abstraction.  The eternal question is how much?


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: separating C from V in MVC

[Rob Nagler]

Dave Rolsky writes:
> The Pet Shop has a grand total of 13 tables.
> 
> How well does this approach work with 90 tables?

Works fine with bivio.com, which has 50 tables.

> How does it handle arbitrary queries that may join 1-6 tables,
> with conditionals and sorting of arbitrary complexity?

The ListModel can override or augment its query.  You can load a
ListModel from an arbitrary data source as a result.  After the load,
it can fix up rows, e.g. computing "percent portfolio" is not done in
SQL but in Perl in internal_post_load_row().

The "automatic" sorting is handy for simple joins.  For complex
queries, there's no fully automatic solution for sorting.

Here's a simple query: http://petshop.bivio.biz/pub/products?p=DOGS
The ListModel declares which columns are sortable:

order_by => [
'Product.name',
'Product.product_id',
],

The view doesn't need to say anything, because the Table widget
queries the ListModel meta-data.  The SQL query is dynamically
constructed by the "o" HTTP query value.

For complex queries, you may be able to take advantage of the sort
infrastructure. There are no guarantees, but you have the rope.

The software is designed for the 80% solution.  As we see patterns
develop in our code, we add general cases to the infrastructure.

> I'm not a big fan of O/R.  I prefer R/O.  But to each their own.

I guess we do R/O in the sense that we design the database
relationally and then map PropertyModels one-to-one with the tables.
Is that what you mean by R/O?

Rob

Re: separating C from V in MVC

[Fran Fabrizio]

>
> > Shop demostrates how you can build a simple application with only a
> > couple of custom SQL queries.  The rest are simple joins and CRUD.  If
> > you need more complex queries, there are escapes.  You still probably
> > end up with a list of tuples for your reports.  The key we have found
> > is avoiding indirection by naming fields and models the same in SQL
> > and Perl objects.  This allows you to seamlessly switch between the
> > two.

>How well does this approach work with 90 tables?  How does it handle
>arbitrary queries that may join 1-6 tables, with conditionals and sorting
>of arbitrary complexity?

I'd have to agree, most of the real-world scenarios I have run across do 
not consist of these neat 1-to-1 field to attribute type of mappings where 
the majority of the queries are simple inserts or selects from a single 
table or simple joins.  Most of the apps I work on quickly evolve to the 
point of many (in my current case, 120+) tables and where most of the 
queries are gathering data for reports/views that bring data together from 
several tables.  Joins of 5+ tables, unions, excepts, subselects, 
self-joins, complex sorting/grouping rules, etc are all commonplace and 
this is where I think overzealous attempts to abstract the queries away 
fall apart.  I guess I'm more of the Perrin school of thought, where I 
prefer crafting all the SQL directly.

I don't typically find apps that just mirror some subset of one of the db 
tables to be all that interesting.  After all, it's the relationships 
between the data that make the data interesting, and by necessity this 
means your queries will be complex.  And looking over the stuff outlined at 
poop.sourceforge.net, there's not too many models/frameworks out there that 
can accurately abstract ALL of SQL, and if it only does a subset, I feel 
like that's shooting myself in the foot.

-Fran

Re: separating C from V in MVC

[Dave Rolsky]

On Fri, 14 Jun 2002, Gunther Birznieks wrote:

> Would one of you mind providing a 1 paragraph definition of each? I am
> afraid that I am starting to get lost in the semantic differences of
> controllers and actions and O/R, R/O?

Well, here's my take on it.

An Object-Relational mapper takes objects and stores them in a relational
database, as transparently as possible.  I think the most pure example of
this I've seen in the Perl world is Tangram (www.tangram-persistence.org).
SPOPS is also an O-R mapper (actually, its a generic Object persistence
mechanism but it seems to most feature-rich when used with an RDBMS).

A Relational-Object takes a relational database, and provides access to it
(select, insert, update, delete) via objects.  Class::DBI, Alzabo, and
DBIx::RecordSet are examples of such a beast.

I think what it comes down to is "how do you start thinking your project?"

If the first thing you think about is classes, objects, hierarchies,
delegation, etc., then an O-R mapper may be for you.  Most applications
need some sort of persistent data storage, and if you think of your app
solely as a collection of objects, then an O-R mapper is a natural fit.

However, if you're like me, and given an app, the first thing you think
about is _data_ and relationships, then a R-O mapper may be better.  I for
one start a project by designing a relational schema for the data.  Then I
want some nice programmatic way to get at it so Alzabo is key for me.

Of course, all this assumes some large amount of persistent data, as is
the case with many (but not all) web apps.

OTOH, if you don't have much (or any) persistent data, this is all
meaningless.  For example, when I work on Mason I think objects.

But when I work on my Hong Kong movie DB project, I think about tables.  I
have 90-some tables and I don't really want to create 90-some individual
classes, plus some ungodly number of "query classes" (as proposed by
Perrin) to deal with it.  Thanks, but no thanks.  OTOH, I hate writing raw
SQL and I hate generating SQL dynamically even more.  Alzabo provides a
nice layer over SQL, provides a multitude of convenience methods, has
hook/trigger support, supports caching, transactions, and facilitates
writing additional "canned query" methods as needed, and much much more ;)


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: separating C from V in MVC

[Gunther Birznieks]

At 12:58 PM 6/14/2002, Dave Rolsky wrote:
>On Thu, 13 Jun 2002, Rob Nagler wrote:
>
>
>I'm not a big fan of O/R.  I prefer R/O.  But to each their own.

Would one of you mind providing a 1 paragraph definition of each? I am 
afraid that I am starting to get lost in the semantic differences of 
controllers and actions and O/R, R/O?

Re: separating C from V in MVC

[Dave Rolsky]

On Thu, 13 Jun 2002, Rob Nagler wrote:

> Most OLTP applications share a lot in common.  The user inputs data in
> forms.  The fields they edit often correspond one-to-one with database
> fields, and certainly their types.  The user wants reports which are
> usually closely mapped to a table/view/join, i.e. an ordered list of
> tuples.
>
> A reasonable O/R mapping can solve this problem easily.  Like Perl, it
> makes the easy things easy and the hard things possible.  The bOP Pet
> Shop demostrates how you can build a simple application with only a
> couple of custom SQL queries.  The rest are simple joins and CRUD.  If
> you need more complex queries, there are escapes.  You still probably
> end up with a list of tuples for your reports.  The key we have found
> is avoiding indirection by naming fields and models the same in SQL
> and Perl objects.  This allows you to seamlessly switch between the
> two.

The Pet Shop has a grand total of 13 tables.

How well does this approach work with 90 tables?  How does it handle
arbitrary queries that may join 1-6 tables, with conditionals and sorting
of arbitrary complexity?

> We've found the O/R mapping to be an indispensable part of the
> system.  Since all data is contained in objects, the views/widgets
> don't need to how the data is populated.  They access all data through
> a single interface.

I'm not a big fan of O/R.  I prefer R/O.  But to each their own.


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: separating C from V in MVC

[Rob Nagler]

Dave Rolsky writes:
> Trying to jam a thick layer of OO-goodness over relational data is asking
> for a mess.

Most OLTP applications share a lot in common.  The user inputs data in
forms.  The fields they edit often correspond one-to-one with database
fields, and certainly their types.  The user wants reports which are
usually closely mapped to a table/view/join, i.e. an ordered list of
tuples.

A reasonable O/R mapping can solve this problem easily.  Like Perl, it
makes the easy things easy and the hard things possible.  The bOP Pet
Shop demostrates how you can build a simple application with only a
couple of custom SQL queries.  The rest are simple joins and CRUD.  If
you need more complex queries, there are escapes.  You still probably
end up with a list of tuples for your reports.  The key we have found
is avoiding indirection by naming fields and models the same in SQL
and Perl objects.  This allows you to seamlessly switch between the
two.

We've found the O/R mapping to be an indispensable part of the
system.  Since all data is contained in objects, the views/widgets
don't need to how the data is populated.  They access all data through
a single interface.

Rob

Re: separating C from V in MVC

[Dave Rolsky]

On Thu, 13 Jun 2002, Perrin Harkins wrote:

> As you can see it gets messy fast, and I didn't even cover the
> Mastercard part.  It would probably have terruble performance too.  This
> is why people usually just write this kind of report as a big SQL query
> instead.  You can make a model object called ConcertSeatSearch:
>
> @seats = Model::ConcertSeatSearch->findSeats(
>   reserved_after => $date,
>   payment_type   => $card,
>   user_state => $state,
>  );
>
> Just be careful that you don't end up making this into something that
> mirrors the SQL exactly.  There might be 4 tables involved in finding
> out what kind of credit card the user had, but that gets hidden behind
> this API.  If you find yourself writing classes that take options like
> "where => 'date > ' . $date" you are reinventing SQL, and you've lost
> your abstraction.

This approach works for some things, but I think it falls down when it
comes to doing complex database searches, particularly searches generated
ad-hoc on multiple columns in multiple tables.

This is why Alzabo is much lower-level than what you have above.  I needed
something where I could easily construct queries that might include 1+
tables, with various types of searches of individual columns in those
tables (equal to, between, less than, like, etc.) with dynamic sorting
(again, on any of the columns in any of the tables, ascending or
descending).

With what you're proposing, I think you could easily end up with either:

A) a ridiculously flexible interface that looks sort of like SQL, except
where it is SQL, except where it's only sort of like SQL, etc.

B) a ridiculous profusion of classes, methods, or both.

SQL has its place, and Alzabo merely provides a thin layer on top of it.

Trying to jam a thick layer of OO-goodness over relational data is asking
for a mess.  OO has its place, but if your application is primarily about
the database, I don't think that a heavy OO layer on top of that will do
you much good.  And OO has a huge impedance mismatch with relational data
(irregardless of SQL or not).


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: separating C from V in MVC

[John Siracusa]

On 6/13/02 1:29 PM, Perrin Harkins wrote:
> Just be careful that you don't end up making this into something that
> mirrors the SQL exactly.  There might be 4 tables involved in finding
> out what kind of credit card the user had, but that gets hidden behind
> this API.  If you find yourself writing classes that take options like
> "where => 'date > ' . $date" you are reinventing SQL, and you've lost
> your abstraction.

"Stringy" stuff like that is certainly a poor abstraction (or no abstraction
at all if it's stuck directly into the SQL!)  But I've done stuff like this:

Pets->get_pets(type => [ 'dog', 'cat' ],
   age  => { and => { gt => 5, lt => 10 } },
   name => { match => 'Fi.*' });

which is powerful enough to do most types of basic selects, but still
abstract enough that the user of this class never actually types SQL
fragments directly.

Of course, the case above is a rarity.  Usually, it'll be used in the simple
form like:

Pets->get_pets(type => 'dog', age => 5);

But just having that more complex form in there for the one or two times you
need it is sometimes valuable, IMO.  And the overhead is minimal if you have
a nice base class that supports all this stuff for you.

-John

Re: separating C from V in MVC

[Perrin Harkins]

Fran Fabrizio wrote:
> Now, how do you represent in the model a
> complex query that joins across 5 of the nouns?

Others have already commented on this, but I want to point out that this 
is a general OO modelling question, not an MVC one, and there are many 
resources available to help you learn this stuff.  I'd suggest getting 
to your local computer book store and browsing through some OO 
programming titles.

> In your concert example, if I wanted to define a report that showed me 
> all of the seats that were purchased by people from New Jersey with a 
> Mastercard in the last week, how would I represent that?

That's a tricky one, because it doesn't make much sense to put all that 
logic about finding users' home states and payment types into a Concert 
class.  You could manipulate the objects to accomplish this:

my @wanted_seats;
my @seats = Model::Concert->findSeatsReservedAfter($date);
foreach my $seat (@seats) {
 if ($seat->person()->address()->state() = 'NJ') {
 push @wanted_seats, $seat;
 }
}

As you can see it gets messy fast, and I didn't even cover the 
Mastercard part.  It would probably have terruble performance too.  This 
is why people usually just write this kind of report as a big SQL query 
instead.  You can make a model object called ConcertSeatSearch:

@seats = Model::ConcertSeatSearch->findSeats(
  reserved_after => $date,
  payment_type   => $card,
  user_state => $state,
 );

Just be careful that you don't end up making this into something that 
mirrors the SQL exactly.  There might be 4 tables involved in finding 
out what kind of credit card the user had, but that gets hidden behind 
this API.  If you find yourself writing classes that take options like 
"where => 'date > ' . $date" you are reinventing SQL, and you've lost 
your abstraction.

- Perrin

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 13:23
> To: Jeff AA
> Cc: [EMAIL PROTECTED]
> Subject: RE: separating C from V in MVC
> 
> 
> >Controller:
> >---
> >my $Stale  = Model::WatchCollection->new( status => 'stale' );
> >
> >Controller:
> >---
> >my $WC= Model::WatchCollection->new();
> 
> Out of these two, I would think that the first one is actually 
> better.  What if you have 300,000 watches and only 25 are stale, for 
> example (numbers that are not all that far from the truth, in my 


Don't make the mistake of fetching all the data when a Collection is
instantiated. It is usually better to make the Collection only really
fetch data when a View actually asks for it by calling $WC->fetch(
status => 'stale' ), after all, sometimes you might go down another
route and the View might never call fetch() - for example if there is an
exception and you decide not to bother showing stale Watches. 

Also, you should generally not fetch everything from the database unless
there is a very good reason to do so. Try to keep your memory usage to a
minimum, and restrict the result set to something useful. I recall a
system that used to pop up a dialog saying 'Warning: This will return
645,345 rows' and the only user option was 'Ok'!

I have seen about 4.2 million Collection designs, and my current
favourite is an abstraction of the Borland Data Engine DB/Table/Dataset
design (BDE) in conjunction with some of the Java collection concepts.
Common Collection niceties include things like 'find me Watch ABC' in
the Collection. A Collection can have the concept of a 'current' thing
so that a View can display both the list of Watches in a table, and more
detailed attributes of the 'currently selected' Watch object etc.

If you are going to support paginated collections, you should build this
into your base Collection class.

So far we have been talking about flat Collections, don't forget that
some of them are not flat, but hierarchical - e.g. tree-like, and some
are circular e.g. no beginning and no end, etc.

ciao
Jeff

Re: separating C from V in MVC

[kyle dawkins]

Fran

> Out of these two, I would think that the first one is actually
> better.  What if you have 300,000 watches and only 25 are stale, for
> example (numbers that are not all that far from the truth, in my
> case)?   That'd be a lot of data I'd be slinging around in the 2nd
> example.  Which is probably what you meant by "might be better". :-)

Jeff's example was very abbreviated to make a point.  In your case, you 
should think about two things:  
1) the representation of your data
2) the fetching of your data

Since you could have a zillion watches, you could use something like

my $staleWatches = WatchManager::watchesWithStatus("stale");

This allows you to implement the "watchesWithStatus" method any way you 
choose, and simply returning an arrayref of matching watches.  Then you 
can pass that arrayref to your View, which, as Jeff says, should apply 
some transform to your data to produce your report.I realise this 
is essentially what Jeff is saying but the key point is that you don't 
need to have all 300,000 watches in memory... you can abstract the data 
using a Manager (or Broker, or... ) so you hide the data store.

Cheers

Kyle Dawkins
Central Park Software

RE: separating C from V in MVC -- something to read. . .

[Vuillemot, Ward W]

This might be of use to some. .
.http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
Just as an intro to MVC -- I have found it invaluable.

Re: separating C from V in MVC

[Perrin Harkins]

Jeff AA wrote:
> I disagree with this definition of a Controller.

I knew someone would.

> A Controller is
> primarily responsible for mapping user input onto a business Model, and
> should not know that buying a ticket requires creation of concert,
> payment, seat, client, theatre, agent, reservation, whatever objects.

Something has to know that stuff.  You can call that something a 
controller, or you can make it a separate module and call it an "action" 
(like an EJB session bean in Java).  Calling it part of the controller 
is an easy way to think about it for people raised on CGI, but does not 
fit exactly with some of the descriptions of MVC you'll find out there. 
  Calling these actions part of the model is fine too.  I don't think it 
matters in most cases, but if your actions (and not just your data 
objects) really do need to be used in the context of multiple UIs then 
you might want this extra step.

> In the concert example, the Controller would interpret the web request,
> create a Ticket object, and call $Ticket->buy(
> %all_the_cleaned_up_params ). It would then pass this to the View to
> render. That's it.

No, I don't agree about that.  It doesn't make sense for a ticket to 
understand how to buy itself.  It should understand how to reserve 
itself, but knowing things like how to process a payment and when to 
e-mail the buyer a receipt have nothing to do with a ticket.

You could make an action class called TicketAgent which would have a 
buy_ticket() method that operates on tickets, payments, and uers to 
accomplish the action of buying a ticket.  I would usually just stick 
that in the controller, but you could separate it if you prefer.

> If you had made the mistake of creating a web Controller aka BuyTicket()
> module that understood it had to create concert, payment, seat, client,
> theatre, agent, reservation, whatever objects, you would have to
> duplicate all this logic AGAIN in the batch process Controller.

No, the data objects are the same in either case but the BuyTicket part 
is very different.  You make a new controller (or action) that accepts 
input and then loads up a whole list of Ticket objects and operates on 
them.  There's usually not a lot of code here, since the details of how 
a ticket reserves itself are all hidden in the Ticket object and the 
details of how a payment gets processed are all hidden inside an Order 
object.  If you do find yourself duplicating code between actions, you 
have the full power of OO programming at your disposal to fix that.

A better argument for action objects would be if you have an e-mail 
interface to your system that lets people buy a ticket, exactly like 
they do through the web interface.  Then you would want to reuse the 
code that operates on the data objects to buy a ticket, so you could 
package that up as a module.

> Models are not just collections of stateful data, they are the right
> place to encapsulate complex business behaviour.

Okay, you convinced me.  Next time I build a big system I'll try putting 
that stuff into action objects.  It's probably overkill for small web 
projects though.

Incidentally, PageKit is probably the closest to the notion of MVC 
you're talking about here.  It doesn't offer any specific help with 
modelling your data as objects, but it follows the structure you 
describe pretty closely and you could use any data modelling module you 
like with it.

- Perrin

Re: separating C from V in MVC

[Jon Robison]

I just wanted to comment on Number 3, here. Scroll down ;-)


kyle dawkins wrote:
> 
> Fran (et al)
> 
> I've stayed out of the MVC chitchat for a long time (very interesting
> thread) because it's such a deep topic.  But seeing as how Fran has
> some concrete questions...
> 
> > 3.  How do you prevent a Controller from just becoming another big if
> > statement, or is this their purpose in life?
> 
> See Jeff's previous mail.  Your structure is crying out for a dispatch
> table; Jeff suggests building this out of a hash that defines what
> actions to perform based on what your query values are.  That's a great
> place to start.   GET RID OF YOUR BIG "IF" STATEMENT ASAP.
> 

If I read this right, then it's something I am already doing and I'll
throw it in here to show:

## My idea of a dispatch table!
my %actions = (
'view' => 'FES::Control::View',
'logout'   => 'FES::Control::Logout',
'edit' => 'FES::Control::Edit',
'notes'=> 'FES::Control::Notes',
'save' => 'FES::Control::Save',
'calendar' => 'FES::Util::Calendar',
);
 
sub handler {
my $r = Apache::Request->new(shift);
 
## BEGIN ignore (DECLINE) image requests and allow regular apache to
handle them.
return DECLINED if $r->content_type =~ /image/;
## END ignore image requests
 
my $act = $r->param('act') || 'view';
 
if (my $h = $actions{$act}) {
$r->push_handlers(PerlHandler => $h);
$r->handler('perl-script');
return DECLINED;
} else {
my $stmt = "There is no such action as \'" . $act . "\'\n";
$r->pnotes('error', $stmt);
$r->push_handlers(PerlHandler => 'FES::Error::Error');
$r->handler('perl-script');
return DONE;
} ## end else [ if (my $h = $actions{$act...
}
1;

That's how I impliment at least _part_ of my controller without
resorting to huge IF statements.

Is this what was meant guys?

--Jon R.

If this is overly simplistic, or not what you meant, feel free to smack
me around.

RE: separating C from V in MVC

[Fran Fabrizio]

Ok so Collections was the missing piece in my puzzle.  Very interesting 
(and intuitive now that you present it to me).

>Controller:
>---
>my $Stale  = Model::WatchCollection->new( status => 'stale' );
>
>Controller:
>---
>my $WC= Model::WatchCollection->new();

Out of these two, I would think that the first one is actually 
better.  What if you have 300,000 watches and only 25 are stale, for 
example (numbers that are not all that far from the truth, in my 
case)?   That'd be a lot of data I'd be slinging around in the 2nd 
example.  Which is probably what you meant by "might be better". :-)

Thanks for the example code, it was very enlightening!  I'll digest further 
at the office this morning.

-Fran

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 06:48
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: separating C from V in MVC
> 
> 
> 
> Ok, great stuff, now we're getting somewhere.  So, the model = the 
> nouns.  Good.  That helps.  Now, how do you represent in the model a 
> complex query that joins across 5 of the nouns?  

In my other post about Controller, I assert [but feel free to disagree!]
that Models are really Nouns+Business Verbs


> network monitoring and display tool.  It receives status 
...
> them."  We call this a stale watch.  We have a report that 
> shows all of the 
> currently stale watches across our network.  The query is a 
> join of around 
> 4 tables (or nouns) - Site, Watch, Watch Config, Message - 
> something along 
> those lines.
> 
> Does one create a model object called StaleWatchReport?  That 

Not generally. Having grasped the core business Model classes, you now
need to also realise that the real world often deals with Collections of
objects. So instead of a StaleWatchReport class, what you need is a
collection of Watches that are stale.

You should ask this collection to present qualifying Watch items.

Collection can be powerful, so give some careful thought to this, and
don't bind your Collection base class too closely to the database (there
was another post by someone on keeping $dbh chroot jailed!)

Here is an example, though there are many other possible collection
approaches.

Controller:
---
my $Stale  = Model::WatchCollection->new( status => 'stale' );
my $View   = View::StaleWatches( stale => $Stale );

$self->headers();
print $View->render();


View::StaleWatches
--
foreach my $watch ( @{$Stale->fetch()} ) {
  describe_in_HTML( $watch );
}

Note that the web controller knows nothing about stale watches, it just
knows that given the current request, it will pass the token 'stale'
into the WatchCollection. You can use the same Model::WatchCollection
class in a batch overnight report, and it too will understand how to
identify stale Watches.

Here is an alternative, possibly better approach:

Controller:
---
my $WC= Model::WatchCollection->new();
my $View  = View::StaleWatches( watches => $WC );

$self->headers();
print $View->render();


View::StaleWatches
--
foreach my $watch ( @{$WC->fetch( status => 'stale' )} ) {
  describe_in_HTML( $watch );
}


In this second example, we have even moved the need for the Controller
to know about 'stale' into the View, which already knew that it only
wanted stale Watches.

> In your concert example, if I wanted to define a report that 
> showed me all 
> of the seats that were purchased by people from New Jersey with a 
> Mastercard in the last week, how would I represent that?
> 

The web request might look like this:
  /seats?qstate=NJ&qcard=MC&qpurchased=-7

Controller:
  my $query = {};
  foreach ( parameter starting with q ) {
$token = param name without the 'q';
$query->{token} = URLDecode(parameter value);
  }
  my $SC = Model::SeatCollection->new( query => $query );
  my $View = View::SeatGeneric->new( seats => $SC );
  $self->headers();
  print $View->render();

Note that the Controller handles decoding the parameters etc, but
doesn't care what queries that the SeatCollection understands. It does
understand a mini protocol where query params start with 'q', but this
is not business logic, it is UI logic.

Next you'll want to know about handling Form validation and Models with
multiple field level exceptions? 8-)

Jeff

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 03:43
> To: Fran Fabrizio; [EMAIL PROTECTED]
> Subject: Re: separating C from V in MVC


> > 2.  Does the first part of my code above even remotely resemble a
> > Controller?
> 
> Sort of.  It does choose a view and it does parse some user 
> input, but a
> controller is more than just a dispatcher.  It would include 
> some of the
> code that you're currently putting into your doDoctorActivity() sub.
> The idea is that the model objects represent just the data in your
> application (the nouns) and the controller understands how to 
> translate
> user input into a series of method calls on the model objects to carry
> out the user's request.
> 
> It's hard to give a good example that is short, but let's say you were
> building an application to sell concert tickets.  The act of 
> buying the
> ticket might involve model objects representing a concert, a user, a
> form of payment, etc.  The concert object knows how to reserve a
> specific seat (or call a seat object to do that).  The payment object
> knows how to verify and charge a credit card.  The user object has a
> mailing address.  The controller knows how to turn the user's 
> form data
> into a bunch of method calls on these objects that accomplish 
> reserving
> the ticket and charging the user.  If you find yourself writing a
> "BuyTicket" module, that's a controller not a model object.
> 

I disagree with this definition of a Controller. A Controller is
primarily responsible for mapping user input onto a business Model, and
should not know that buying a ticket requires creation of concert,
payment, seat, client, theatre, agent, reservation, whatever objects.

In the same way that the View keeps the output format independent of the
Model properties, the Controller keeps the User Input method independent
of business logic. This is the reason for having a Controller class.

Consider that your mod_perl website Controllers will have to understand
all about web requests, headers, error headers, cookies, sessions,
redirects, URLs and URL decoding etc etc - these are things that relate
directly to how the user is interacting with the Model.

In the concert example, the Controller would interpret the web request,
create a Ticket object, and call $Ticket->buy(
%all_the_cleaned_up_params ). It would then pass this to the View to
render. That's it.

Consider the case where you wanted to buy hundreds or even thousands of
tickets in a batch process - maybe you have agents that collect all the
details for Kylie concerts, and then send them to you in a file.

If you had made the mistake of creating a web Controller aka BuyTicket()
module that understood it had to create concert, payment, seat, client,
theatre, agent, reservation, whatever objects, you would have to
duplicate all this logic AGAIN in the batch process Controller. You now
have to maintain the business logic in two places.

Always keep the _business_ behaviour in Models. The $Ticket->buy()
processing must instantiate and create relationships to all the other
objects it needs.

Put all things that are specific to handling the User Interaction (eg
web request) into your Controller. Business logic always goes into a
Model.


> The idea is that the model objects represent just the data in your
> application (the nouns) and the controller understands how to 
> translate
> user input into a series of method calls on the model objects to carry
> out the user's request.

Models are not just collections of stateful data, they are the right
place to encapsulate complex business behaviour. At the risk of
repetition, all behaviour [e.g. $Ticket->buy()] that is not specific to
the User Interface should go into Models. 

Controller and View are closely related elements of GUI. This is like
the old 'Two Tier App' problem... when business logic and GUI become
inexorably entwined, maintenance goes out the window.

Have a look at this picture:
http://www.ddj.com/documents/s=867/ddj0105i/0105if2.htm which comes from
this article: http://www.ddj.com/documents/s=867/ddj0105i/0105i.htm


Maybe in the future, we will get drag-and-drop via the web -
interpreting this should go into the Controller. 

Maybe in the future you will change the business requirements for buying
Tickets - this will go in a Model, and the effect will be felt
consistently in both your web applications and your batch processing.

Regards
Jeff

Re: XML vs Perl (Re: separating C from V in MVC)

[Matt Sergeant]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 13 June 2002 6:20 am, Rob Nagler wrote:
> Matt Sergeant writes:
> > > This assumes you need XML in the first place.
> >
> > No, it does not. The rest of my post spoke about XML as a
> > data format and set of tools, not as a syntax. Please stop
> > thinking about XML as syntax!!
>
> If my entire system is written in Perl, why do I need XML as a data
> format?

Need is *not* what I said. But anyway, I already said: because of the tools.

Perl has nothing that even comes close to SAX as a clean way of doing the 
"unix"-like thing of having small tools to do just one job when it comes to 
data munging.

> Perl's data structures are richer and have much more support
> in Perl than XML has in any language.  Perl has been around much
> longer and is full-fledged programming language.  It has better
> tools.  It's got a larger community.

We disagree on this.

> > You seem to speak as someone who has never tried by the sounds of
> > things. This is one of the things AxKit's XSP taglibs are designed
> > to provide for.
>
> I've never used XSP.  I have used XSLT, tried to use XSD, and am
> currently mired in DocBook/XML.  One of my sites generates XML for its
> data export format.
>
> Let's take an XSP example from axkit.org:
>
> 
>   Time::Object
> 
>
> 
>
> Why is the above better than below?  (I cleaned up the perl :-)
>
> use Time::Object;
> sub mytime {
>   my ($time) = @_;
>   return Time::Object->new($time || time);
> }
>
> Or, why can't I just call Time::Object->new where I need it?

Erk. I knew the docs on AxKit.org were going to bite me in the ass one day. 
This is a really *bad* example of XSP usage. It's not separating content from 
presentation. Nowadays everything I do uses taglibs, which makes pages look 
like:

  http://axkit.org/NS/xsp/wiki/1";>


  

(yes, I'm writing an axkit wiki in case anyone's interested)

Anyway, that's off topic, because the point was you were trying to argue 
(IIRC) why would you bother hand generating XML from your data just to get 
access to XML tools. But XSP's two taglib modules (look at the docs on 
search.cpan.org, rather than on axkit.org) do that conversion automatically 
for you.

- -- 
<:->get a SMart net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9CErhVBc71ct6OywRAn67AJ9E9o+MAnvkbXutEycFk+y7LAEVQwCfeUuI
95rN/7rb51T9wLJgY3EamL0=
=c8HN
-END PGP SIGNATURE-

Re: separating C from V in MVC

[Fran Fabrizio]

Ok, great stuff, now we're getting somewhere.  So, the model = the 
nouns.  Good.  That helps.  Now, how do you represent in the model a 
complex query that joins across 5 of the nouns?  For example, our app is a 
network monitoring and display tool.  It receives status messages from 
sites nationwide, and makes a web interface.  (It does other things but 
this will do for now).  One of the reports we run is called "stale 
watches", which basically means "we expected to receive a message from site 
Foo reporting on the status of Bar (say, CPU Load), and we didn't hear from 
them."  We call this a stale watch.  We have a report that shows all of the 
currently stale watches across our network.  The query is a join of around 
4 tables (or nouns) - Site, Watch, Watch Config, Message - something along 
those lines.

Does one create a model object called StaleWatchReport?  That seems to me 
to be suspiciously like an action by another name.  But that's the only way 
I can see this thing working, because otherwise, the Controller is going to 
get in the business of defining what a StaleWatchReport means and start 
having to deal with DBI record sets.  I can't quite imagine what this 
StaleWatchReport would look like.

In your concert example, if I wanted to define a report that showed me all 
of the seats that were purchased by people from New Jersey with a 
Mastercard in the last week, how would I represent that?

I guess what I am getting at is that I see how if I wanted to present 
someone with the list of Sites, or even the list of Sites that met some 
criteria (newer than one month old, or whatever), I could have a Site 
object in the model that had a getSiteList() method that took an optional 
date range or whatever.  But I get lost when trying to figure out how 
result sets that are the result of a join or relationship between "noun"s 
would be represented.

I hope that makes sense. =)

-Fran

XML vs Perl (Re: separating C from V in MVC)

[Rob Nagler]

Matt Sergeant writes:
> > This assumes you need XML in the first place.
> 
> No, it does not. The rest of my post spoke about XML as a
> data format and set of tools, not as a syntax. Please stop
> thinking about XML as syntax!!

If my entire system is written in Perl, why do I need XML as a data
format?  Perl's data structures are richer and have much more support
in Perl than XML has in any language.  Perl has been around much
longer and is full-fledged programming language.  It has better
tools.  It's got a larger community.

> You seem to speak as someone who has never tried by the sounds of
> things. This is one of the things AxKit's XSP taglibs are designed
> to provide for.

I've never used XSP.  I have used XSLT, tried to use XSD, and am
currently mired in DocBook/XML.  One of my sites generates XML for its
data export format.

Let's take an XSP example from axkit.org:


Time::Object




Why is the above better than below?  (I cleaned up the perl :-)

use Time::Object;
sub mytime {
my ($time) = @_;
return Time::Object->new($time || time);
}

Or, why can't I just call Time::Object->new where I need it?

When I first started working with DocBook/XML, I thought there were
all these great tools.  When I tried to install dblite, it took me two
hours and it still didn't work.  I had to install a particular version
of Java for the XSLT program.  Fortunately, Perl was already
installed, which dblite uses for glue.  The *.xslt files have to be
configured to be found by the XSLT program.  And on and on it went.

I said to myself, "Self, this is a trivial problem.  Let's see how
long it takes me to hack something in Perl."  Two hours later
I had a working DocBook/XML to HTML translator, which was good enough
for my needs.

Later I decided to make this into an example program.  This new
program processes about 50 different DocBook/XML tags and includes a
word counter for XML files.  It is 340 lines including comments and
POD.  Source: http://petshop.bivio.biz/src?s=Bivio::XML::DocBook

Compare this to dblite which has 5400 lines of XSLT in 6 files and
about 3000 lines of Perl to glue it all together.  This doesn't
include Sax or Xalan, which are the java programs you need to run
XSLT.

XML solves a problem through an indirection.  It's very similar to
CORBA IDL in that it is a language which is used as a least common
denominator between heterogeneous languages/systems.  This is a good
use for XML.  (BTW, if you look at the committees from the OMG and the
committees in the XML world, you'll see a surprising overlap.  I
wonder if they'll be successful this time.)

While every software problem can be solved through another layer of
indirection, every layer of indirection also creates a new software
problem.

Rob

Re: separating C from V in MVC

[Perrin Harkins]

Wow, this is a long one.  As usual, everyone has slightly different
ideas about how to do MVC, so keep a grain of salt handy.

> This basic pattern repeated ad infinitum.  It's grown way out of
> control, is a pain to work with, and just feels wrong, very wrong. :-)

We've all been there.

> 1.  Is there one Controller or many?

Usually there are many.

> Should I have one for each main
> area of my site?  /myapp/admin/ goes to an Admin Controller,
> /myapp/reports to another controller, etc...

That's how I would do it.  The idea is to group the things that are
related together, since they tend to change at the same time.

> 2.  Does the first part of my code above even remotely resemble a
> Controller?

Sort of.  It does choose a view and it does parse some user input, but a
controller is more than just a dispatcher.  It would include some of the
code that you're currently putting into your doDoctorActivity() sub.
The idea is that the model objects represent just the data in your
application (the nouns) and the controller understands how to translate
user input into a series of method calls on the model objects to carry
out the user's request.

It's hard to give a good example that is short, but let's say you were
building an application to sell concert tickets.  The act of buying the
ticket might involve model objects representing a concert, a user, a
form of payment, etc.  The concert object knows how to reserve a
specific seat (or call a seat object to do that).  The payment object
knows how to verify and charge a credit card.  The user object has a
mailing address.  The controller knows how to turn the user's form data
into a bunch of method calls on these objects that accomplish reserving
the ticket and charging the user.  If you find yourself writing a
"BuyTicket" module, that's a controller not a model object.

> 3.  How do you prevent a Controller from just becoming another big if
> statement, or is this their purpose in life?

If you break up your app into multiple controllers, there will probably
only be a few different actions that each one handles.  That's a pretty
small if statement, or you could use a dispatch table.  Modules like
CGI::Application have already written the dispatch table code for you,
so you just provide the configuration that maps actions to subroutines.

> 4.  In the case of a form, what perl structure is used to pass the
data
> into the model?

You don't pass a form directly to a model object.  You parse the form,
then you use the API provided by the model object.  Remember, we want to
be able to use these same model objects from a cron job.

my $hospital = $apr->param('hospital');
$doctor->set_hospital($hospital);

> 5.  Do you create an actual class for each form?

Similar to #1, each form might have it's own controller class, or you
might group some related forms (that act on the same data) together in a
single controller.

> 6.  Do you need to create objects at all?  Is OO a prerequisite to
MVC?

Modelling your data as objects is sort of an underlying assumption in
MVC.  You could do a clean design without using OO, but it would be a
little odd and the model objects might not be very reusable.

> 6.5.  (thought of while proofreading :-)  Is the statement "there is
one
> set of controllers for each defined view" correct?

No.

> In other words, if
> we someday want to output the "reports" section of the site as Excel
> spreadsheets in addition to HTML, would we define a new set of
> controllers or how would that work?

You would make your existing controllers understand the piece of user
input or context that means they want Excel format, and have them pass
the model data to a different view in that case.

> 7a.  Is it insane to leave my SQL hard-coded in there?

You're going to have SQL somewhere, but if you wrap it up into objects
that represent your data, it's easier to maintain.  It hides all of that
specific database knowledge from the rest of the application and avoids
repitition.

At eToys we had a tremendous amount of data associated with each
product.  It spanned many tables and was not very easy to work with.
However, once I had written an object representing a product, the search
code, shopping cart code, product page code, etc. could all use it.
When we added new properties, I only had to do it one place.

OO modelling is a big subject and lots of good books have been written
on it, so I won't say more about it here.

> 7b.  Should I really investigate real object persistence like
discussed
> at the POOP site (I have used Tangram with some success on tiny side
> projects but nothing remotely this size)?

Only if you like what it does for you.  I generally prefer to write the
SQL myself because of the tuning opportunities it affords, but this is
the sort of topic that many people have strong opinions on.  Anyway,
objects that contain hand-coded SQL are just as real as objects that use
a POOP module to generate the SQL for them.

> Begging the question, shou

Re: separating C from V in MVC

[kyle dawkins]

Fran (et al)

I've stayed out of the MVC chitchat for a long time (very interesting 
thread) because it's such a deep topic.  But seeing as how Fran has 
some concrete questions...

> 3.  How do you prevent a Controller from just becoming another big if
> statement, or is this their purpose in life?

See Jeff's previous mail.  Your structure is crying out for a dispatch 
table; Jeff suggests building this out of a hash that defines what 
actions to perform based on what your query values are.  That's a great 
place to start.   GET RID OF YOUR BIG "IF" STATEMENT ASAP.

> 6.  Do you need to create objects at all?  Is OO a prerequisite to
> MVC? 

No, but it makes it a lot easier in most cases.  Passing objects between 
the M, the C and the V is way easier than building crappy hashes by 
hand and calling a zillion "param" methods.

> 7a.  Is it insane to leave my SQL hard-coded in there?  The queries
> don't change all that much, and it's nice to have the query in the
> same place as the processing of the result set so you can kind of
> "see" the structure of the result set better.  This helps our
> less-experienced developers.

OK, strong words here.  REMOVE YOUR SQL.  Move it into a layer that 
deals with the DB and vends consistently formed data (objects if you 
can manage it).Your controller shouldn't know anything about your 
DB, so create a class that essentially is every entry and exit point to 
and from your DB, and have that keep the database handle as a class 
variable.  What's easier for your newbie programmers... your code as it 
is now, or this:

sub doDoctorActivity {
  my $tmpl = shift;
  my @results = DataStore::objectsForDoctorActivity();
  ViewManager::someMungingMethod($tmpl, \@results);
  return $tmpl;
}

Think of how clean your code is with no more $dbh references or "ifs".  
Think how many fewer lines of code you will have to maintain.   Fewer 
lines is good.  Remember that.

It is a HUGE gain to isolate your DB entry points and place them in one 
carefully controlled class.

I am often amazed at how blind some developers can be about SQL.  Most 
of the people on this list realise that mixing HTML and perl is bad, 
and most of us can see why.  But I am constantly depressed that not 
nearly as many people appreciate that it is THE SAME FOR PERL AND SQL.  
SQL intermixed with Perl is just nasty and you need to move it into a 
limited space that you can easily control.  Obviously, it's necessary; 
you need your perl to talk to your DB.  But  it should be very very 
carefully managed and moved somewhere where its impact on the source is 
minimal. Right now I have the evil task of optimising a zillion lines 
of bad perl code written by a company I used to work for.  They have 
asked me to come back and save the project... and it's a frigging mess 
because of all the SQL.  THere are so few places where you can cache 
query results, for example, because there are pages and pages of crap 
like

$sql .= " AND some_other_stupid_table.id = 
another_dumbass_table.stupid_table_id";
if ($myAssIsBlue) {
 $sql .= " AND some_table.my_ass IN ('BLUE','BLUISH','CYAN')";
}

ad nauseum.  What a load of utter shite.

> 7d.  Or do I -really- want an object/structure that represents every
> result set we need to get back from the database?

If I were you I would create a parent class that represents a basic DB 
row and use that.  When you need custom behaviour, subclass it and 
bless the rows into the subclass.  Adding an "Object Structure" can be 
as simple as blessing your hashes that come back from the DB into a 
class, remember that.

> 8a.  What structures are used to pass back the data from the model
> through the controller to the view?
> 8b.  The view is expecting HTML::Template style hashes and arrays, do
> I form these in the model (which seems to be too much knowledge of
> the view while still in the model) or does the controller convert it
> to the structures expected by the HTML::Template view?
> 8c.  The model is getting DBI record sets from the db.  I have to put
> this data into -something-, why not the exact format that
> HTML::Template view needs rather than process it twice?

Well, pretend you actually had objects coming back from your DB.  Surely 
your controller should pass those objects to your view as is...?  
That's the whole point.   Your view should be responsible for 
displaying them.  I have seen a lot of talk about HTML::Template being 
a "View" layer.  It's not.  It's the bottom of the View layer.  You 
need to write the top of the view layer yourself, that takes your data 
(objects, whatever) and vends it to HTML::Template in the right way.

Kyle Dawkins
Central Park Software

RE: separating C from V in MVC

[Jim Martinez]

On Jun 12  Jeff wrote:

> 
> 
> > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> > Sent: 12 June 2002 21:48
> 
> Nothing indepth, just a quick response ...

I too am using mod_perl just for Apache::Registry, and would also like to
look for alternatives.

Answers the questions posed by Fran would also help me and I bet other 
lurkers (L).  Even just 

Jim

JampL
aka
Japh wannabe

RE: separating C from V in MVC

[Jeff]

> From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 21:48

Nothing indepth, just a quick response, but it looks like your huge if
statement can be replaced using a hash. Maybe something like:

# just an eg, this data is static and can be required from
# your startup.pl so that all child get a shared copy
%global::dispatch = (
  summary => { template => 'summary', actions => [ 'doSummary',
'doOther' ] },
  doctor  => { template => 'docact,   actions => [ 'healthyself', ] },
)

# In your generic Controller / Handler
if ( exists $global::dispatch{$template} ) {
  my $dispatch = $global::dispatch{$template};
  my $tmpl = getTemplate( $despatch->{template} );
  foreach my $function ( @{$dispatch->{actions} ) {
&$function($dbh,$tmpl);
  }
  print header . %tmpl->output();
} else {
  unavailable();
}

The nice thing about this is you end up with a generic Controller, and
can separate the config off somewhere else. The Controller will probably
change much less than your config, so separation makes sense.

I don't really see an issue with the Controller being responsible for
returning the response, after all it fielded the request in the first
place. I would try hard to keep ALL HTML in the View world - whether you
create a View class or use a templating approach. 

0.02c

Regards
Jeff

Re: separating C from V in MVC

[Fran Fabrizio]

Ok, thanks to you all and this great discussion I want to try to make 
our current project into an MVC-style app, so what now?  This MVC 
discussion could not have come at a better time - our little app is all 
grown up now and needs a real architecture.  I have read the MVC threads 
in depth now, and I have questions.  

WHERE WE ARE NOW
--  

We have a multiuser application that has about oh, I dunno, 100 
different "screens" to the interface.  They can be roughly divided into 
the following areas - status, admin, registration, reports, and graphs. 
 Most of the actions involve either retrieving data from a database or 
processing a form and inserting into a database (in other words, it's a 
very typical web application).  This application started as a CGI 
script.  For performance reasons, we installed mod_perl and use 
Apache::Registry to run it now.  It's pretty much still a dumb CGI 
script with a mod_perl wrapper, but I did develop a couple of modules to 
do user authentication with AuthCookie-based solutions and tied that 
into Apache::Session for state maintenance between requests.  The CGI 
script has grown to accomodate these ~ 100 actions and is now basically 
a 4,000 line if statement.  The script decides which request to do based 
on a target= parameter passed in (in other words, target=summary or 
target=doctoractivity, etc...).  For sanity's sake, many months ago, we 
switched to HTML::Template (our view) to define our screens, which has 
worked well to date.  On the back end we have PostgreSQL with a healthy 
sized schema of around 150 tables or so that has ~ 350 megs of data and 
on the order of 500,000 transactions a day (lots of data turnover, some 
tables get UPDATEd so frequently as to have 100% data turnover within 15 
minutes).  Anyways, back to the perl part

Basic code structure:

[snip]
my $dbh = DBI->connect( $r->dir_config('RMSDBI_DSN') , 
$r->dir_config('RMSDBI_user') , $r->dir_config('RMSDBI_password') );

# giant if statement - closest thing I have to a controller, I suppose
if ($target = 'summary') {
  my $tmpl = getTemplate('summary');
  doSummary($dbh,$tmpl);
  print header . $tmpl->output();
} elsif ($target = 'doctoractivity') {
  my $tmpl = getTemplate('doctoractivity');
  doDoctorActivity($dbh,$tmpl);
  print header . $tmpl->output();
} elsif ...

[snip]

# lots of subs basically one per target, closest thing I have to a 
model, I suppose
sub doSummary {
  ($dbh, $tmpl) = shift;
  $sth = $dbh->prepare("SQL STATEMENT HARD-CODED HERE");
  # process result set into hashes and arrays of hashes such as @summary 
that HTML::Template wants
  [snip]
  $tmpl->param(summary => @summary);
}

sub doDoctorActivity {
  ($dbh, $tmpl) = shift;
  $sth = $dbh->prepare("SQL STATEMENT HARD-CODED HERE");
  # process result set into hashes and arrays of hashes such as @summary 
that HTML::Template wants
  [snip]
  $tmpl->param(summary => @summary);
}

etc

This basic pattern repeated ad infinitum.  It's grown way out of 
control, is a pain to work with, and just feels wrong, very wrong. :-) 
 To be fair, it grew very fast and it was all we (by we I mean the two 
of us that were this entire dept. back then) could do to keep up with 
the feature requests, let alone worry about proper architecting of the 
software.  We're paying for it now, of course.

WHERE WE WANT TO BE
--

I would like to introduce some semblance of organisation, sanity, 
maintainability, separation of logic, etc to this project.  In other 
words, MVC would be a good fit.  

Some of the concrete, basic questions I have are:
1.  Is there one Controller or many?  Should I have one for each main 
area of my site?  /myapp/admin/ goes to an Admin Controller, 
/myapp/reports to another controller, etc...
2.  Does the first part of my code above even remotely resemble a 
Controller?  I mean, it takes the input, calls essentially a 'model' 
object (but passing it the view object, nice, eh? =), but then seems to 
break the model nicely by doing things like printing out the HTML from 
the Controller, etc...
3.  How do you prevent a Controller from just becoming another big if 
statement, or is this their purpose in life?
4.  In the case of a form, what perl structure is used to pass the data 
into the model?
5.  Do you create an actual class for each form?
6.  Do you need to create objects at all?  Is OO a prerequisite to MVC?
6.5.  (thought of while proofreading :-)  Is the statement "there is one 
set of controllers for each defined view" correct?  In other words, if 
we someday want to output the "reports" section of the site as Excel 
spreadsheets in addition to HTML, would we define a new set of 
controllers or how would that work?

Now onto the model, I think I have a little better grasp of the model 
compared to the controller, but I have questions...
7a.  Is it insane to leave my SQL hard-coded in there?  The queries 
don't change all that much, and it's n

Re: separating C from V in MVC

[Matt Sergeant]

On Wednesday 12 June 2002 4:09 am, Rob Nagler wrote:
> Matt Sergeant writes:
> > There's quite a few things that are a lot harder to do with XML in
> > plain perl (especially in SAX) than they are in XSLT.
>
> This assumes you need XML in the first place.

No, it does not. The rest of my post spoke about XML as a data format and set 
of tools, not as a syntax. Please stop thinking about XML as syntax!!

> It's trivial to manipulate Perl data structures in Perl.  It's
> also easy to manipulate XML in Perl.  However, it's impossible(?) to
> manipulate Perl data structures in XSLT.

You seem to speak as someone who has never tried by the sounds of things. This 
is one of the things AxKit's XSP taglibs are designed to provide for.

Matt.

Re: separating C from V in MVC

[Gerald Richter]

> Gerald Richter wrote:
> > Embperl 2.0 can invoke such a controller (it's called application object
> > there) after it has setup it's request parameters (GET/POST data,
session
> > data, etc.) and before any templates are get a chance to run.
>
> That sounds like a good addition to Embperl.  Can you give a URL for the
> documentation on how to use this?
>

http://search.cpan.org/doc/GRICHTER/Embperl-2.0b7/Embperl/Object.pm contains
a short paragraph about it (search for EMBPERL_OBJECT_APP ) and inside the
Embperl distribution is an example application  (see eg/web).

I am currently working on improveing the docs for Embperl 2.0, since a lot
of nice new features are rarly documented right now

Gerald


-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

RE: separating C from V in MVC

[Rob Nagler]

Jeff AA writes:
> Sounds interesting, can you briefly describe the MVCF parts, and what
> their responsibilities are?

http://www.bivio.biz/hm/why-bOP contains a decent explanation of how
we think about MVC.  There's also a talk with notes:
http://www.bivio.biz/hm/csci7818-bop-intro/intro

> Have you split the View into View + Facade?

Views and the Controller request values from the Facade configured for
the incoming request or command line function.  Models don't really
need to talk to the Facade, since Models should be purely internal and
the Facade is about user interface elements.  Models do manipulate the
HTTP form values (which are not UI elements imo) and query strings
(which are part of the UI, but we don't map query keys via the Facade).

A couple of people have mentioned the concept of a "container".  We
call this concept Attributes:
http://petshop.bivio.biz/src?s=Bivio::Collection::Attributes

MVC components are derived from attributes.  A Task has attributes
(name, number, permissions, items to execute, next).  A View has
attributes (parent, variables).  Widgets are configured with
attributes (cell_bgcolor, string_font, etc.).  Models have attributes
(fields).  A Request has attributes (path_info, port, auth_user, etc.).

Attributes proved to be a significant breakthrough in the
simplification of the interfaces.  The views and widgets don't know
about models for the most part.  They can just as easily format the
incoming server name from the request and the user's name from a
model.  And you can flow seamlessly between them, e.g.

['auth_user', 'name']

This widget value is the name attribute from the model identified by
the request's auth_user attribute.

Facade components are bit different, because their values are often
hierarchical and grouped, e.g. you want to group the namespace of the
"alt" tags for icons separately from other in spaces:
$fc->group(Image_alt => [
dot => '',
goback => 'Back',
continue => 'Continue',
]);

or you want to group a bunch of symbolic font names to a single font
specification:

$fc->group([qw(
strong
bold
table_row_title
)] => ['bold']);

You also want to be able to manipulate these values in clones and
children of facades.  The Attributes class is a simple one to one
mapping..

However, FacadeComponents do support the WidgetValueSource interface
which means Font values can be accessed by Widgets just like other MVC
components.

> What are the differences between your MVCF and the MVP pattern?

I didn't know what the MVP pattern was.  I don't think the MVP pattern
is applicable to Web interfaces.  GUIs are fundamentally different
from HTTP.  HTTP is stateless, screen-oriented, and client-server.

One of the reasons why Perl is so well suited to the Web is that you
don't need asynchrony (threads) and you do need to manipulate lots of
strings.  The Web is a "transformational" system.  GUIs are
interactive systems.

> > URLs are part of your user interface, not your controller.
> I think I like this, though the w3 might not 8-)

The W3C is dreaming if they think there ever going to get rid of
people typing in Web addresses.

Even if they somehow magically get rid of them, people will still
bookmark them.  This means you need multiple URL mappings to the same
operation for backwards compatibility.  We have rearranged our site URLs
several times, but we kept the old mappings.  The URLs for the entire
site are contained in a single file.  A Task can have multiple
mappings, but always has a single primary URL.

> I find that the mix of business object e.g. Bank Account and
> presentation objects, e.g. Table can lead to confusion - are your Table
> objects just a way of organising data, or do they contain presentation
> style hints -e.g. dynamic width indication etc?

Table is a Widget.  BankAccount is a Model.

> Do you have something similar to a Bank Account object with some primary
> properties and containing a collection of current Transaction
> objects?

There are no transaction objects.  You can push transaction resources
on the request and if the Task completes successfully, they will be
committed.

> Or do you focus on the presentation style objects - Tables, nested
> Tables, Lists etc?

We do the whole thing.  Config, tracing, alerts, OR mapping, command
line abstraction, etc.  It's the same thing you having just about
every modern OLTP system.  We looked back pretty far to get where we
are now. :-)

> I looked over your site and code, compact and impressive - probably a
> stupid question, but are there any higher-level overviews of your
> approach / framework?

There isn't more documentation except for the classes themselves.  The
best way is to download bOP and start twiddling with it.

Thanks, btw.  Our goal is compactness, but not in the sendmail.cf
sense. :-)  It's certainly not everybody's cup of tea.  For a microview
of the declarative style, checkout:
http://petshop.bivio.biz/src?s=B

Re: separating C from V in MVC

[Rob Nagler]

Matt Sergeant writes:
> There's quite a few things that are a lot harder to do with XML in
> plain perl (especially in SAX) than they are in XSLT.

This assumes you need XML in the first place.

It's trivial to manipulate Perl data structures in Perl.  It's
also easy to manipulate XML in Perl.  However, it's impossible(?) to
manipulate Perl data structures in XSLT.

Rob

Re: separating C from V in MVC

[Perrin Harkins]

Gerald Richter wrote:
> Embperl 2.0 can invoke such a controller (it's called application object
> there) after it has setup it's request parameters (GET/POST data, session
> data, etc.) and before any templates are get a chance to run.

That sounds like a good addition to Embperl.  Can you give a URL for the 
documentation on how to use this?

- Perrin

Re: separating C from V in MVC

[Gerald Richter]

> >
> > [% Ctrl.Search() %]
> >
> > makes Controller::Search any less a controller.
>
> You're right.  It just looks kind of odd to me, invoking a template for
> something that is not a display-related task.  It looks like the way
> people typically do MVC in Mason or Embperl, with a first template that
> doesn't do anything but invoke a module to take over the processing.
>

Embperl 2.0 can invoke such a controller (it's called application object
there) after it has setup it's request parameters (GET/POST data, session
data, etc.) and before any templates are get a chance to run. So this
application object is able to do the necessary processing and give back
parameters to Embperl so the right templates will be displayed, according to
the result of the controllers processing.

This approach has the benefit that Embperl does the tasks that need to be
done for every request, so you don't have to care about it and can
concentrate on the real controller functions. Additionaly it implements an
object orientated approach, so you can get addtional benefits by spliting up
your controllers functionality in different application objects, which
inherit from each other. (same inherence schema can be used for templates)

Gerald


-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

Re: separating C from V in MVC

[Ron Pero]

At 01:01 PM 06/11/02 -0400, John Siracusa wrote:
>On 6/11/02 12:46 PM, Perrin Harkins wrote:
>> John Hurst wrote:
>>> Still, I don't think that replacing this:
>>> 
>>> 
>>>SetHandler  perl-script
>>>PerlHandler Controller::Search
>>> 
>>> 
>>> with this:
>>> 
>>> [% Ctrl.Search() %]
>>> 
>>> makes Controller::Search any less a controller.
>> 
>> You're right.  It just looks kind of odd to me, invoking a template for
>> something that is not a display-related task.  It looks like the way
>> people typically do MVC in Mason or Embperl, with a first template that
>> doesn't do anything but invoke a module to take over the processing.
>
>...but it has several advantages.  I particularly appreciate being able to
>add to or change parameters or behaviors before passing things off to the
>controller, for example.  I can have several "variants" of the same
>controller living at different URLs, all pointing back to a single
>controller object.

This is how CGI::Application works, but instead of calling a template page,
it calls a script. The script is tiny -- defines a "run mode", and perhaps
parameters -- then calls the main script that does the heavy lifting, which
in turn instantiates standard modules that provide standard functionality.

I was intrigued by it, because at the time I was using a different approach
with shopping software: each link or form action called the same script,
which would figure out what needed to be done. Kind of like the tail wags
the dog instead of the other way around.

This is outside of MVC, but is nonetheless intriguing. I'm wondering if, in
another 2-3 years, after the authors of the several Perl application
frameworks have had more time to refine their designs, there will be
convergence of issues like this.

Am I wrong, or is this field of web applications a developing field for
which there is no textbook principles of how to do it? Perl has enabled
several people to take different approaches to it, whereas Microsoft's ASP
is just one approach, PHP is just one approach, and I don't know if Java
has multiple approaches or what. Will the various Perl approaches converge
toward a common set of principles, and/or reveal as yet undiscerned
patterns and architectures? Or maybe I'm imagining too much here...

Ron

>
>Don't think of it as "invoking a template."  Just think off it as an
>inverted dispatch mechanism: the actions camp out at their locations, as
>opposed to having their locations (in the httpd.conf) pointing at the
>controller modules.  Or something... :)
>
>-John
>
>

Re: separating C from V in MVC

[Valerio_Valdez Paolini]

On Tue, 11 Jun 2002, John Siracusa wrote:

> > You're right.  It just looks kind of odd to me, invoking a template for
> > something that is not a display-related task.  It looks like the way
> > people typically do MVC in Mason or Embperl, with a first template that
> > doesn't do anything but invoke a module to take over the processing.
>
> ...but it has several advantages.  I particularly appreciate being able to
> add to or change parameters or behaviors before passing things off to the
> controller, for example.  I can have several "variants" of the same
> controller living at different URLs, all pointing back to a single
> controller object.

I think that it is also more manageable by people who doesn't want to
understand configurations; designers who worked with me found this
approach handy.

> Don't think of it as "invoking a template."  Just think off it as an
> inverted dispatch mechanism: the actions camp out at their locations, as
> opposed to having their locations (in the httpd.conf) pointing at the
> controller modules.  Or something... :)

And it is a sort of grid layout, mentioned by someone in a previous
message; but it still remains an impure approach :(

Ciao, Valerio



 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

Re: separating C from V in MVC

[John Siracusa]

On 6/11/02 12:46 PM, Perrin Harkins wrote:
> John Hurst wrote:
>> Still, I don't think that replacing this:
>> 
>> 
>>SetHandler  perl-script
>>PerlHandler Controller::Search
>> 
>> 
>> with this:
>> 
>> [% Ctrl.Search() %]
>> 
>> makes Controller::Search any less a controller.
> 
> You're right.  It just looks kind of odd to me, invoking a template for
> something that is not a display-related task.  It looks like the way
> people typically do MVC in Mason or Embperl, with a first template that
> doesn't do anything but invoke a module to take over the processing.

...but it has several advantages.  I particularly appreciate being able to
add to or change parameters or behaviors before passing things off to the
controller, for example.  I can have several "variants" of the same
controller living at different URLs, all pointing back to a single
controller object.

Don't think of it as "invoking a template."  Just think off it as an
inverted dispatch mechanism: the actions camp out at their locations, as
opposed to having their locations (in the httpd.conf) pointing at the
controller modules.  Or something... :)

-John

Re: separating C from V in MVC

[Perrin Harkins]

John Hurst wrote:
> Still, I don't think that replacing this:
> 
> 
>SetHandler  perl-script
>PerlHandler Controller::Search
> 
> 
> with this:
> 
> [% Ctrl.Search() %]
> 
> makes Controller::Search any less a controller.

You're right.  It just looks kind of odd to me, invoking a template for 
something that is not a display-related task.  It looks like the way 
people typically do MVC in Mason or Embperl, with a first template that 
doesn't do anything but invoke a module to take over the processing.

> Obviously, the stand-alone dynamic pages are not MVC at all. They exist
> because there are often 'glue' pages that don't warrant the comlexity of MVC
> (those that don't need M and have very simple VC needs).

I agree that there is often a need for some quick and dirty internal-use 
pages (admin or reporting usually) that don't require the extra baggage.

- Perrin

Re: separating C from V in MVC

[Perrin Harkins]

Ward Vuillemot wrote:
> I know we are straying WOT, but I would love to get a better feel for XML, XSLT and 
>AxKit.

Barrie Slaymaker has written a couple of articles on perl.com that serve 
as a good intro to AxKit.

- Perrin

Re: separating C from V in MVC

[Matt Sergeant]

On Tue, 11 Jun 2002, Ward Vuillemot wrote:

> I know we are straying WOT, but I would love to get a better feel for
> XML, XSLT and AxKit.  There are a lot of different systems out there. .
> .and part of me wants to just do it my way (in large part to learn), but
> I also realize that I really want to get to the business of also being
> productive.
>
> Per the below, I would imagine some would say XML in and of itself is
> not worth considering as a contender for being the basis for our C of
> MVC.  AxKit bills itself as an XML application.  Would ppl suggest just
> using an XSLT parser. . .or is it worth looking at AxKit.
>
> If anyone is willing to share their experiences, knowledge, insight --
> off the ML is okay, too -- I would _really_ appreciate it!

A while ago (couple of months I think) on the AxKit-Dahut IRC channel Eric
Cholet was raving about how he had discovered how cool XML was.

What really happened was that Eric discovered that XML isn't about the
Syntax, which seems to be what everybody focuses on (especially perl
people I find). The beauty of XML is in the tools. Things like SAX, which
allow you to build a pipeline of specialised tools for munging data, are
really why XML is so great.

I really can't put it as well as Eric did at the time. I only hope by
using his name out loud here I can prompt him to post something ;-)

Basically I would just suggest that the set of tools for manipulating XML
are better than most of the other tools you currently use for munging data
about. Taken a step further, while perl is cool at munging text, most of
us don't just deal with text - we deal with trees, records, etc. So by
combining Perl and XML you get the best of both those worlds. The XML
solutions I've seen tend to be the least "hacked" looking systems I've
seen in my relatively few years of experience.

I know that's not specifically about AxKit. What AxKit does offer is a
mature stable system for bringing these tools together, plus it offers
nice ways to deliver the same content in different formats.

-- 

<:->Get a smart net

Re: separating C from V in MVC

[Ward Vuillemot]

I know we are straying WOT, but I would love to get a better feel for XML, XSLT and 
AxKit.  There are a lot of different systems out there. . .and part of me wants to 
just do it my way (in large part to learn), but I also realize that I really want to 
get to the business of also being productive. 

Per the below, I would imagine some would say XML in and of itself is not worth 
considering as a contender for being the basis for our C of MVC.  AxKit bills itself 
as an XML application.  Would ppl suggest just using an XSLT parser. . .or is it worth 
looking at AxKit. 

If anyone is willing to share their experiences, knowledge, insight -- off the ML is 
okay, too -- I would _really_ appreciate it!

Thanks,
Ward

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Monday 10 June 2002 11:23 pm, Vuillemot, Ward W wrote:
>>:  Really interesting, xml
>>:  appears to be
>>:  the final destination for most of us, even if now i
>>:  prefer objects.
>>:
>>:  Ciao, Valerio
>>
>> That is my big question.  Is XML/XSLT really the right solution?  Using SAX
>> along with having tags call handlers seems like a pretty powerful way to
>> get a very cool tool to build powerful templating services.  I haven't
>> decided if XSLT really is worth the effort as it just seems like a
>> glorified XML (yes; it is indeed) -- what I mean to say, does XSLT really
>> have any real value since everything it does can be done in Perl.  If I got
>> make handlers for XSLT, too -- then why even use XSLT?  Just go back to
>> plain XML and do it all on my own, no?
>
>There's quite a few things that are a lot harder to do with XML in plain perl 
>(especially in SAX) than they are in XSLT. It's really hard to explain this 
>to anyone who hasn't yet learned XSLT's template model, but the simplest 
>thing to describe is that looping back to previous tags is really hard with 
>SAX (you have to use some sort of node caching technique).
>
>One thing a lot of people will argue is that XSLT is verbose and ugly. And I 
>totally agree. But get over it. Perl is ugly too. But once you start using 
>XSLT for any length of time you start to realise just why it is designed like 
>it is, and you start to appreciate that design (and this is from someone who 
>has so far designed *two* alternatives to XSLT!).
>
>- -- 
><:->get a SMart net
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQE9BZcbVBc71ct6OywRAv81AKDMDkWvAOhwY3A0vDlxxHSK7Y6qOACgm3ni
>VRLe9kmR9i3tDcMJAKr8d7s=
>=2Xpn
>-END PGP SIGNATURE-
>
>
 

--
Ward W. Vuillemot
[EMAIL PROTECTED]

Re: separating C from V in MVC

[James A Duncan]

On Tuesday, June 11, 2002, at 01:37 PM, Chris Winters wrote:

> On Mon, 2002-06-10 at 13:29, Ray Zimmerman wrote:
>> So how is everybody else handling URL mapping? Do others group this
>> kind of data together with fonts, colors, etc?  And where do you
>> define it?
>
> A single mod_perl handler catches all requests, looks up the URL in the
> action table and dispatches the request to the appropriate handler. That
> handler is free to pass on the request to other actions as well, since
> every part of the system is able to lookup actions based on a key.

Currently OpenFrame does something similar.  We have a slot which 
dispatches to an application based on the URL.  However, I think for 
future versions applications will be 'slots', and they can just do 
something or nothing depending on the URL, which allows multiple 
applications to run on the same request, which fixes my 'how the heck do 
I make subrequests work' nightmare.

We're also going to provide a 'forced' mvc style Application type in the 
next version[0] which will be a container that has a model, a view, and 
a controller.  The data that each of the MVC elements provides will 
simply be passed from one to the other inside the container.

As what may be a departure from the norm, in OpenFrame templates, or a 
templating system is *not* the view part of MVC.  Templates simply 
decide where to place the data on the screen  - the view class does all 
the formatting and prep work.

Regards,
James.

[0] of course this is the next version that has been being written for 
the last 3 months and not gotten anywhere.  Sooner or later I will get 
around to turning thought into code, and then all will be right and good 
in the world[1].

[1] or at least in my world

Re: separating C from V in MVC

[Chris Winters]

On Mon, 2002-06-10 at 13:29, Ray Zimmerman wrote:
> So how is everybody else handling URL mapping? Do others group this 
> kind of data together with fonts, colors, etc?  And where do you 
> define it?

As Perrin mentioned, OpenInteract does this by allowing individual
packages (distributable applications) to define the handlers they
support. A package does this by defining actions which at server startup
get collected into a data structure called the action table.

A single mod_perl handler catches all requests, looks up the URL in the
action table and dispatches the request to the appropriate handler. That
handler is free to pass on the request to other actions as well, since
every part of the system is able to lookup actions based on a key.

Entries in the action table can also be used as components --
displayable items that don't stand by themselves but contribute to a
full page. Examples include boxes, common search forms, dependent object
listings, etc.

Currently, here's what an action looks like, as found in the 'base_user'
package distibuted with OpenInteract:

$action = {
'user'=> {
'class'=> 'OpenInteract::Handler::User',
'security' => 'no',
},
'newuser' => {
'class'=> 'OpenInteract::Handler::NewUser',
'error'=> [ 'OpenInteract::Error::User' ],
'security' => 'no',
},
};

All information is available through a lookup to the action table.

One of the modifications I'm working on now will allow you to add more
information to the action and have it available in an object that is
instantiated by the dispatcher which then tells the object to run
itself.

Chris
 
-- 
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.

RE: separating C from V in MVC

[Jeff AA]

> From: Rob Nagler [mailto:[EMAIL PROTECTED]] 
> Sent: 10 June 2002 20:41

> ... a Facade is the front face of the web site which includes colors,
> text, URLs, etc.  All the other MVC components talk to the currently
> selected Facade when they need these values.

> The controller calls Bivio::UI::Task->parse_uri, which strips the
> "*" from the URL (if there) and sets the facade before parsing
> the rest of the URL.  The default Facade is www.bivio.biz, which is
> why we don't need a rewrite.

> The links are generated by the Facade component Bivio::UI::Task.

Sounds interesting, can you briefly describe the MVCF parts, and what
their responsibilities are? Have you split the View into View + Facade?
What are the differences between your MVCF and the MVP pattern?

> This allows the Facade to pick its own URLs.  
...
> URLs are part of your user interface, not your controller.

I think I like this, though the w3 might not 8-)


> We rarely change the controller except to add new function.  
> Query and form values are parsed by the Models after they are 
> translated to key/value format by the controller.  

I definitely like this - small number of relatively generic Controllers
seems to me to be a desirable goal of an MVC arch.

> abstracted the concept of paging and drill down in our ListModel and 
> Table classes.  

I find that the mix of business object e.g. Bank Account and
presentation objects, e.g. Table can lead to confusion - are your Table
objects just a way of organising data, or do they contain presentation
style hints -e.g. dynamic width indication etc? 

Do you have something similar to a Bank Account object with some primary
properties and containing a collection of current Transaction objects?
Or do you focus on the presentation style objects - Tables, nested
Tables, Lists etc?

I looked over your site and code, compact and impressive - probably a
stupid question, but are there any higher-level overviews of your
approach / framework?

TIA
Jeff

Re: separating C from V in MVC

[Matt Sergeant]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday 10 June 2002 11:23 pm, Vuillemot, Ward W wrote:
>:  Really interesting, xml
>:  appears to be
>:  the final destination for most of us, even if now i
>:  prefer objects.
>:
>:  Ciao, Valerio
>
> That is my big question.  Is XML/XSLT really the right solution?  Using SAX
> along with having tags call handlers seems like a pretty powerful way to
> get a very cool tool to build powerful templating services.  I haven't
> decided if XSLT really is worth the effort as it just seems like a
> glorified XML (yes; it is indeed) -- what I mean to say, does XSLT really
> have any real value since everything it does can be done in Perl.  If I got
> make handlers for XSLT, too -- then why even use XSLT?  Just go back to
> plain XML and do it all on my own, no?

There's quite a few things that are a lot harder to do with XML in plain perl 
(especially in SAX) than they are in XSLT. It's really hard to explain this 
to anyone who hasn't yet learned XSLT's template model, but the simplest 
thing to describe is that looping back to previous tags is really hard with 
SAX (you have to use some sort of node caching technique).

One thing a lot of people will argue is that XSLT is verbose and ugly. And I 
totally agree. But get over it. Perl is ugly too. But once you start using 
XSLT for any length of time you start to realise just why it is designed like 
it is, and you start to appreciate that design (and this is from someone who 
has so far designed *two* alternatives to XSLT!).

- -- 
<:->get a SMart net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9BZcbVBc71ct6OywRAv81AKDMDkWvAOhwY3A0vDlxxHSK7Y6qOACgm3ni
VRLe9kmR9i3tDcMJAKr8d7s=
=2Xpn
-END PGP SIGNATURE-

Re: separating C from V in MVC

[John Hurst]

Perrin Harkins wrote:
> 
> On Mon, 10 Jun 2002, I wrote:
> >
>>In the filesystem. Directly requested .tt files are all sent to a
>>default template handler:
> 
> Those are both interesting and may be the most appropriate solution for
> the problems you're working on, but I wouldn't call either of them MVC.
>   You are going straight to a view (template) and letting it drive all
> the decisions.  In an MVC application, you would go to a controller that
> would do some work and then decide which view to show.

I have three kinds of templates:

  controller entry stubs - called directly to invoke a controller
  view pages - called by controllers to display results
  stand-alone dynamic pages - called directly, may not invoke controller

I would agree with you if my entry stubs did more than call up the controller,
but those templates are simple one-liners that do nothing else. Once the
controller has been called it takes over, processing request data, calling
models, selecting views, etc. The only influence a stub template has on the
view is that of defining the URL that the controller inherits (plus optional
parameters as shown in my earlier message).

Yes, a developer could make a mess of things by trying to put more stuff into
a controller entry stub. We all seem to agree that any scheme can be polluted
by poor discipline, and the arrangement I have described is as prone to abuse
as any other. Still, I don't think that replacing this:


   SetHandler  perl-script
   PerlHandler Controller::Search


with this:

[% Ctrl.Search() %]

makes Controller::Search any less a controller.

I could enforce the separation of controller entry stubs from stand-alone
templates and view templates by using additional file extensions and handlers,
but no one has abused the system as it is so I'm erring on the side of my own
laziness. Using the entry stub templates is handy because I don't need to mangle
the server configuration to make controllers available from other locations
(which means I can stay at the pub while others toil away).

Obviously, the stand-alone dynamic pages are not MVC at all. They exist
because there are often 'glue' pages that don't warrant the comlexity of MVC
(those that don't need M and have very simple VC needs). It is much more
convenient to code such pages in the same environment as the MVC stuff (that
is, using the same globally defined variables, macros, etc.).


-jh

Re: separating C from V in MVC

[Valerio_Valdez Paolini]

On Mon, 10 Jun 2002, Matt Sergeant wrote:

> > It seems perfect for mod_perl2. Really interesting, xml appears to be
> > the final destination for most of us, even if now i prefer objects.
>
> There's no conflict between using XML and using Objects if you're using AxKit.
> Especially thanks to Simon Cozen's nice new taglib.

I know also this; i subscribed Axkit ml on 31 May 2000, but still does not
have the courage to look at xml and co. :) I'll post a question on the
other ml, ok?

Ciao, Valerio



 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

RE: separating C from V in MVC

[Vuillemot, Ward W]

   :  Really interesting, xml 
   :  appears to be
   :  the final destination for most of us, even if now i 
   :  prefer objects.
   :  
   :  Ciao, Valerio


That is my big question.  Is XML/XSLT really the right solution?  Using SAX
along with having tags call handlers seems like a pretty powerful way to get
a very cool tool to build powerful templating services.  I haven't decided
if XSLT really is worth the effort as it just seems like a glorified XML
(yes; it is indeed) -- what I mean to say, does XSLT really have any real
value since everything it does can be done in Perl.  If I got make handlers
for XSLT, too -- then why even use XSLT?  Just go back to plain XML and do
it all on my own, no?

Part of me wants to go XML as it seems like nearly embraced technology.  And
having the parsing, et cetera handled by something other my own Perl seems
like a good way to remove some headaches and let me get to the job of coding
useful things.  ;)

Re: separating C from V in MVC

[Matt Sergeant]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday 10 June 2002 11:09 pm, Valerio_Valdez Paolini wrote:
> On Mon, 10 Jun 2002, James G Smith wrote:
> > I'm working on a framework that will use the Mason component as the
> > controller, Perl modules as the model, and either Mason components or
> > TT templates called from the controller as the view.  The view would
> > output XML that would then be put through AxKit or similar by the
> > autohandler to add style information and produce HTML or whatever
> > format we needed.
>
> It seems perfect for mod_perl2. Really interesting, xml appears to be
> the final destination for most of us, even if now i prefer objects.

There's no conflict between using XML and using Objects if you're using AxKit. 
Especially thanks to Simon Cozen's nice new taglib.

- -- 
<:->get a SMart net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9BSVWVBc71ct6OywRAtMWAJ94l9mq+ZMWduAMHRD81mHV+a0V7gCgg/bP
jPXqIBNKQD64RDnDRLatSBM=
=wH5R
-END PGP SIGNATURE-

Re: separating C from V in MVC

[Valerio_Valdez Paolini]

On Mon, 10 Jun 2002, James G Smith wrote:

> I'm working on a framework that will use the Mason component as the
> controller, Perl modules as the model, and either Mason components or
> TT templates called from the controller as the view.  The view would
> output XML that would then be put through AxKit or similar by the
> autohandler to add style information and produce HTML or whatever
> format we needed.

It seems perfect for mod_perl2. Really interesting, xml appears to be
the final destination for most of us, even if now i prefer objects.

Ciao, Valerio


 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

Re: separating C from V in MVC

[Valerio_Valdez Paolini]

On Mon, 10 Jun 2002, Perrin Harkins wrote:

> Those are both interesting and may be the most appropriate solution for
> the problems you're working on, but I wouldn't call either of them MVC.
>   You are going straight to a view (template) and letting it drive all
> the decisions.  In an MVC application, you would go to a controller that
> would do some work and then decide which view to show.

You are right, I know this problem, but think at components as second level
controllers, where i can work with Model and View. The ugly thing is having
html, which belongs to View, in two places with Controller in the middle.
The main focus here is to be friendly with ui people, shifting reusability
towards them.

Thank you for your comment!

Ciao, Valerio


 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

Re: separating C from V in MVC

[James G Smith]

Valerio_Valdez Paolini <[EMAIL PROTECTED]> wrote:
>
>> Ray Zimmerman wrote:
>> So how is everybody else handling URL mapping?
>
>On Mon, 10 Jun 2002, John Hurst wrote:
>
>> In the filesystem. Directly requested .tt files are all sent to a
>> default template handler:
>[...]
>> % cat admin/proj-edit.tt
>> [% Ctrl.DBEdit.run(ObjectType => 'Project') %]
>
>I used html pages with augmented tags parsed by a standard handler:

I'm doing something similar, but using a database (and caches) for
url<->filename mappings (usually to Mason components, searching the
component root path) and then using a filter in the autohandler to
change urls of the form "comp:docs/index" to a url that maps to that
component.

This lets me rearrange the public view of the site without moving any
files and allows me to rearrange the files without changing the
public view.

I'm working on a framework that will use the Mason component as the
controller, Perl modules as the model, and either Mason components or
TT templates called from the controller as the view.  The view would
output XML that would then be put through AxKit or similar by the
autohandler to add style information and produce HTML or whatever
format we needed.

The end result is that the work-code (model) is indepenent of
interface, the controller is independent of view, and the view is
somewhat (via XML) independent of look&feel.

I don't have benchmarks yet to demonstrate its non-scalability.
-- 
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: separating C from V in MVC

[Perrin Harkins]

Valerio_Valdez Paolini wrote:
> On Mon, 10 Jun 2002, John Hurst wrote:
> 
> 
>>In the filesystem. Directly requested .tt files are all sent to a
>>default template handler:
...
> I used html pages with augmented tags parsed by a standard handler:

Those are both interesting and may be the most appropriate solution for 
the problems you're working on, but I wouldn't call either of them MVC. 
  You are going straight to a view (template) and letting it drive all 
the decisions.  In an MVC application, you would go to a controller that 
would do some work and then decide which view to show.

- Perrin

Re: separating C from V in MVC

[Valerio_Valdez Paolini]

> Ray Zimmerman wrote:
> So how is everybody else handling URL mapping?

On Mon, 10 Jun 2002, John Hurst wrote:

> In the filesystem. Directly requested .tt files are all sent to a
> default template handler:
[...]
> % cat admin/proj-edit.tt
> [% Ctrl.DBEdit.run(ObjectType => 'Project') %]

I used html pages with augmented tags parsed by a standard handler:



this way i can instantiate classes, named components, and call
their methods. Programmers write classes wich in turn call templates.
Designer can control 1) graphic layout by moving 'images' (and other
tags of course) 2) view details modifying templates.

There are other high level tools:






functions can use variables and fill placeholders. Every component
can interact with the handler, receiving context infos (possibly
including session data) and answering with some content plus HTTP
codes, which seem to me quite explanatory.

If someone wants to know more, please ask. This framework works in
few dinamic sites here in Italy and is very handy to use, especially
during periodic reorganization of the site (structure, design).

Thank you for the excellent OT!

Ciao, Valerio



 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

Re: separating C from V in MVC

[Rob Nagler]

Ray Zimmerman writes:
> (1) What are you using to display the nice syntax-colored Perl source 
> at http://petshop.bivio.biz/ ?

We fix up the output from perl2html with our SourceCode widget:

http://petshop.bivio.biz/src?s=Bivio::UI::HTML::Widget::SourceCode

The pod looks better when formatted as "#" comments.  (Yes, we know
there is a but with the first #.  :-)  We also add links to other
classes and views, since perl2html doesn't do this for you.

> (2) Are you using the term Facade in the same sense as in Design 
> Patterns p. 185?

No, a Facade is the front face of the web site which includes colors,
text, URLs, etc.  All the other MVC components talk to the currently
selected Facade when they need these values.

We map Facades in the front-end, e.g. petshop.bivio.biz and
www.bivio.biz are two Facades in the same server:


ServerName www.bivio.biz

SetHandler perl-script
PerlHandler Bivio::Agent::HTTP::Dispatcher



ServerName petshop.bivio.biz
RewriteRule ^(.*) /*petshop$1 [L,PT]

SetHandler perl-script
PerlHandler Bivio::Agent::HTTP::Dispatcher



The controller calls Bivio::UI::Task->parse_uri, which strips the
"*" from the URL (if there) and sets the facade before parsing
the rest of the URL.  The default Facade is www.bivio.biz, which is
why we don't need a rewrite.

> It seems that some of it 
> is data that is used strictly by the View (colors, fonts) and other 
> parts (URL mapping) are used by the View (for generating links) and 
> Controller (for calling the View or doing a redirect).

The links are generated by the Facade component Bivio::UI::Task.
Redirects are issued by the controller or sometimes the models.  In
all cases, we identify Tasks, not URLs.  This allows the Facade to
pick its own URLs.  It means an URL can be anything, and you don't
have to have ".tt", ".asp", etc. suffixes or put then in a particular
directory, e.g. "cgi-bin" or WebObjects+Foo+Bar.  URLs are part of
your user interface, not your controller.

Typically, you might put all icons in a special directory, i.e. we use
/i/, and then have a special mapping on your front-end servers that
avoids hitting your mod_perl servers.

One comment on Perrin's statement:
> In an MVC system, you would definitely need to edit the controller any 
> time you change the input side of the user interface.  You may or may 
> not need to change the model and view as well.

We rarely change the controller except to add new function.  Query and
form values are parsed by the Models after they are translated to
key/value format by the controller.  Only when HTTP changes do we need
to change the controller.

We've also abstracted the concept of paging and drill down in our
ListModel and Table classes.  We haven't had a need to change that
abstraction for some time.  There are only so many user input patterns
you need for even the most complex applications.

Rob

Re: separating C from V in MVC

[John Hurst]

> Ray Zimmerman wrote:
> So how is everybody else handling URL mapping?

In the filesystem. Directly requested .tt files are all sent to a
default template handler:


 SetHandler perl-script
 PerlHandler UAL::TTEngine


AddType text/tt .tt
Action text/tt /tt_engine>

The default template handler provides a list of controllers via the
Stash, allowing the layout people to place a link to a controller
anywhere. Controllers may be re-used with modified behavior:

% cat admin/proj-edit.tt
[% Ctrl.DBEdit.run(ObjectType => 'Project') %]

% cat admin/task-edit.tt
[% Ctrl.DBEdit.run(ObjectType => 'Task') %]

% cat admin/usermanager.tt
[% Ctrl.UserManager.run() %]

% cat admin/mailclient.tt
[% Ctrl.MailClient.run() %]

% cat user/mailclient.tt
[% Ctrl.MailClient.run(AllowPOP3 => 0, AllowIMAP => 0, AllowMIME => 0) %]




-jh

Re: separating C from V in MVC

[Perrin Harkins]

Ray Zimmerman wrote:
> So how is everybody else handling URL mapping?

In httpd.conf:


   SetHandler  perl-script
   PerlHandler Controller::Search



   SetHandler  perl-script
   PerlHandler Controller::ShoppingCart


Most applications only have a handful of controllers, so this works fine.

You could also look at the way OpenInteract does it, which allows you to 
gather all the related stuff including this configuration into a single 
package that you can install in one shot.

- Perrin

Re: separating C from V in MVC

[Ray Zimmerman]

At 12:02 AM -0600 6/6/02, Rob Nagler wrote:
>To solve this problem, we added a letter.  bOP is MVCF, where F stands
>for Facade.  A Facade allows you to control icons, files, colors,
>fonts, text, and tasks.  You can add other components, but we usually
>use text as a catch all, e.g. numeric formats.  Facades can inherit
>from other facades and can be cloned from other facades.  We use this
>to support different skins and co-brands.



>A Facade is the first thing set in a request.  You then know what
>tasks are available and what URLs map to them.  Take a look at:
>http://petshop.bivio.biz/src?s=Bivio::PetShop::Facade::PetShop
>All the URLs for the site are contained in this file.  Anybody
>rendering a URL, does it through Bivio::UI::Task.

Two specifically for Rob ...

(1) What are you using to display the nice syntax-colored Perl source 
at http://petshop.bivio.biz/ ?


(2) Are you using the term Facade in the same sense as in Design 
Patterns p. 185?  If not, could you define what a facade is in terms 
of its role?  I'm planning an MVC-type architecture for my web-app 
and am looking for a place to put the kinds of data you have in your 
Facade - URL mappings, colors, fonts, etc. It seems that some of it 
is data that is used strictly by the View (colors, fonts) and other 
parts (URL mapping) are used by the View (for generating links) and 
Controller (for calling the View or doing a redirect).

... and one for everybody ...

So how is everybody else handling URL mapping? Do others group this 
kind of data together with fonts, colors, etc?  And where do you 
define it?

Very much appreciating all the MVC discussion ...

-- 
  Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)

[Tony Bowden]

On Sat, Jun 08, 2002 at 08:51:48AM +0800, Gunther Birznieks wrote:
> >I'm a huge fan of passing Date::Simple objects, which can then take a
> >strftime format string:
> >  [% date.format("%d %b %y") %]
> >  [% date.format("%Y-%m-%d") %]
 
> And the latter does not require a programmer?

Of course not. It just requires someone who can read a simple chart of
strftime formats. I've never worked with a designer who hasn't been able
to understand the DESCRIPTION section of, for example,
  http://unixhelp.ed.ac.uk/CGI/man-cgi?strftime+3

It wouldn't be difficult to make up a more "designer friendly" version
of it if it was really needed.

Tony

Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)

[Ed]

On Fri, Jun 07, 2002 at 09:14:25AM +0100, Tony Bowden wrote:
> On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote:
> > > Suppose you have a model object for a concert which includes a date.  On
> > > one page, the designers want to dipslay the date in a verbose way with
> > > the month spelled out, but on another they want it abbreviated and fixed
> > > length so that dates line up nicely.  Would you put that formatting in
> > > the controller?
> > In the script:
> > 
> >$template->param(long_date  => $long_date,
> > short_date => $short_date);
> > In the template:
> > 
> >The long date:   
> >The short date: 
> 
> Can I vote for "yick" on this?
> 
> A designer should never have to come to a programmer just to change the
> formatting of a date.
> 
> I'm a huge fan of passing Date::Simple objects, which can then take a
> strftime format string:
> 
>   [% date.format("%d %b %y") %]
>   [% date.format("%Y-%m-%d") %]
> 
> Tony
> 

xmlns:date="http://exslt.org/dates-and-times";  wins for me.

date:date-time()
date:date()
date:time()
date:month-name()
... etc

xslt solutions win for me because it its supported (or seems to be)
by many major languages, and applications. 

xslt stylesheets can be processed, reused and shared with my c,perl,
java,javascript, ruby, mozilla, ieexplorer ... kde apps, gnome apps
... etc

Imagine having your templates and data supported and interoperable ...

Aren't we trying to rid the world of proprietary (only works here) things?

Ed   (an axkit lover)

Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)

[Gunther Birznieks]

At 04:14 PM 6/7/2002, Tony Bowden wrote:
>On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote:
> > > Suppose you have a model object for a concert which includes a date.  On
> > > one page, the designers want to dipslay the date in a verbose way with
> > > the month spelled out, but on another they want it abbreviated and fixed
> > > length so that dates line up nicely.  Would you put that formatting in
> > > the controller?
> > In the script:
> >
> >$template->param(long_date  => $long_date,
> > short_date => $short_date);
> > In the template:
> >
> >The long date:   
> >The short date: 
>
>Can I vote for "yick" on this?
>
>A designer should never have to come to a programmer just to change the
>formatting of a date.
>
>I'm a huge fan of passing Date::Simple objects, which can then take a
>strftime format string:
>
>   [% date.format("%d %b %y") %]
>   [% date.format("%Y-%m-%d") %]

And the latter does not require a programmer?

RE: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)

[Jesse Erlbaum]

Hey Tony -- 

>I'm a huge fan of passing Date::Simple objects, which can then take a
>strftime format string:
>
>  [% date.format("%d %b %y") %]
>  [% date.format("%Y-%m-%d") %]


Out of curiosity, at what point of flexibility do you feel it is OK for your
designers to go back to the programmers?  In your book, where does a bit of
flexibility "cross the line"?


-Jesse-

Re: separating C from V in MVC

[Chris]

::realizes this may be going a bit futher a field ... but tries to maintain 
topicality::

> Chris writes:
>> Perl handels Regex's better than C, this is one of the reasons people
>> use  Perl.
> 
> I disagree.  Perl's Regex processor is written in C.  The difference is
> that it has outgrown Henry Spencer's regexp library.

Mmm semantic differences I yield the floor seneator, but I wish it to go on 
the record that Regex's are built into the main syntax of the Perl 
language, and are fully supported by the culture. While you must 
specifically link to and consiously add in Regex's in C. You can build a 
Hash, Queue and Stack in C as well, but that doesn't mean that they aren't 
generally simpler to use in Perl because they're built right into the 
language.
 
>> It makes (some) hard things easy and (some) impossible things 
>> hard ... within it's domain. XSLT is no different. Use the appropriate
>> tool  (or Toolkit) for the problem.
> 
> Agreed.  Perl is good at text manipulation.  It is imiho superior to
> XSLT in all spaces which XSLT claims to solve.  Once you have an XML
> parse tree in Perl, it's trivial to write a translator to any format
> more correctly than XSLT.  My favorite example is XML to CSV.  Every
> example I've seen in XSLT is cumbersome and wrong.  You'd think it
> wouldn't be hard, but try it. ;-)
 
Well XSLT wasn't really designed (and shouldn't have been) to output plain 
text. Despite what the W3C says. It's designed to tranlsate between XML 
Vocabularies. I'll explain in a bit why I feel that XSLT is better suited 
for this than Perl.

>> existance beyond the Towers of Hanoi problem. But I haven't seen it
>> solved  in TeX either (::know's there's gotta be a link for this::).
> 
> I'm sure Randall wrote a TeX to TT translator to generate his TT
> version of ToH. ;-)

Merlyn any comments here? Other Powers-That-Be? I could see this as a 
JAPH ... only for size N problems it would take N^2 years to print.

>> Rob, is what you are suggesting that one should not use a turing
>> complete  language for visual markup or that simply the language
>> should be the best  match for the solution? I'm just looking for
>> clarity on your position.
> 
> The question really surrounds "little languages".  Perl is ideally
> suited to creating them.  There's no reason to invent a new syntax ([%
> %]) or semantics for standard structures.  I think you should write
> classes in Perl that map to some interface which defines the language.

This is where I think we have a disagreement. In usability circles there is 
an idea that different things should be ... well ... different. If one 
button turns on the radio ... it shouldn't look anything like the button 
that launches the missles. 

This is why I find XSLT well suited for XML->XML transformations because it 
is visually/ideologically well suited to it's primary domain. If I'm 
dealing with the angle brackets and the tree structure ... then I'm 
thinking about the angle brackets and the tree structure ... eventually I'm 
zenning in the whole Angle Brackety Tree Structury-ness of the world. (I 
have a degree in english I know exactly how awful that sentance was.) 

It may be true that Perl can do it quicker and faster ... but for me the 
advantage to visually distinguishing the logically different parts helps 
future maintainability.

C and Perl are distinctly different because the domains they are best 
suited (and designed) for are distinctly different. Nobody wishes Perl's 
syntax were more like that of C, Java, or Cobol. If they do they should 
probably be writing C, Java or Cobol. (Inline::Cobol anyone?) 

In MVC if each letter were written in it's own language it would be very 
easy to maintain the seperation. If it's generally impractical to use three 
distinct languages* one should keep as much visual distinction between the 
three as possible.


*Generally people already do use three langauges though with the Template 
Language (HTML|ASP|TT|XSLT), the Controller Language (Perl) and the Model 
Language (SQL).

> It's pretty much gotten to the point where nobody gets fired for
> choosing Java.  I've lost many contract bids because I didn't say Java
> was the right solution.  I haven't lost a single customer who let us
> solve the problem for them.
 
People don't approach a contractor and tell them what tools to build a 
house with. Why do they insist on doing it with programmers?


-Chris

-- 
"[A] Genuinely skillful use of obscenities is uniformly absent on the 
Internet." -Karl Kleinpaste 

Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)

[Tony Bowden]

On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote:
> > Suppose you have a model object for a concert which includes a date.  On
> > one page, the designers want to dipslay the date in a verbose way with
> > the month spelled out, but on another they want it abbreviated and fixed
> > length so that dates line up nicely.  Would you put that formatting in
> > the controller?
> In the script:
> 
>$template->param(long_date  => $long_date,
> short_date => $short_date);
> In the template:
> 
>The long date:   
>The short date: 

Can I vote for "yick" on this?

A designer should never have to come to a programmer just to change the
formatting of a date.

I'm a huge fan of passing Date::Simple objects, which can then take a
strftime format string:

  [% date.format("%d %b %y") %]
  [% date.format("%Y-%m-%d") %]

Tony

Re: separating C from V in MVC

[Chris]

::really hesitates to step into this ... but like a train wreck ... he 
simply can't resist::

>> It's like asking why XML has different syntax and semantics from Perl.
> 
> Well, if you read the XSLT spec and then look at an XSLT program,
> you'll see a lot of verbosity and a lot of general purpose constructs
> like variables, conditionals, and loops.  I haven't done much with
> XSLT, but I do know you can get it in an infinite loop.  That seems
> pretty general purpose to me.
 
Well aside from the fact that XSLT is Turing complete (And thus 
theoretically as "powerful" as Perl or C or Java) the syntax structure of 
XSLT (because it is a derivitive of XML) makes it difficult to do some 
things (try writing a version of sed in XSLT). This I think was the 
original point. 

Perl handels Regex's better than C, this is one of the reasons people use 
Perl. It makes (some) hard things easy and (some) impossible things 
hard ... within it's domain. XSLT is no different. Use the appropriate tool 
(or Toolkit) for the problem.

> I think the rule is: if you can solve Towers of Hanoi in the language,
> its general purpose enough.  True formatting languages, such as,
> Scribe do not contain general-purpose constructs, so you couldn't
>solve the Towers of Hanoi.  HTML is another good example (ignoring
>

Re: separating C from V in MVC

[Andy Wardley]

On Thu, Jun 06, 2002 at 08:15:24PM -0600, Rob Nagler wrote:
> The issue here is not whether TT is a bad approach, but rather why the
> syntax is not Perl.  

One reason is that I like to have minimal syntax in the templates.  One
argument often used is that non-programmer find it easier to say foo.bar
than $foo->{ bar }.  But I think the more compelling argument is that
even experienced programmers find it easier to write.  It's just less
syntax.  I don't mind syntax in my Perl programs, it serves an important
purpose there.  But in my templates, I prefer to have everything as 
simple as possible.

Another reason is that foo.bar deliberately abstracts the difference
between $foo->{ bar } and $foo->bar().  You can change the underlying
implementation of a data structure and you don't need to update your
templates.

A third reason is that by abandoning strict Perl syntax I can be much
more flexible in providing a domain specific language tailored to the 
task of generating and manipulating content.  

A

Re: separating C from V in MVC

[Matt Sergeant]

On Fri, 2002-06-07 at 03:15, Rob Nagler wrote:
> Agreed.  Perl is good at text manipulation.  It is imiho superior to
> XSLT in all spaces which XSLT claims to solve.  Once you have an XML
> parse tree in Perl, it's trivial to write a translator to any format
> more correctly than XSLT.  My favorite example is XML to CSV.  Every
> example I've seen in XSLT is cumbersome and wrong.  You'd think it
> wouldn't be hard, but try it. ;-)

XSLT is an XML to XML transformation tool. Seems fairly obvious to me
it's not going to do XML to CSV very well. For that you use SAX.

I disagree with you in all uses of transforming an XML tree into another
XML tree.

Right tool for the job, as always.

Matt.

Re: separating C from V in MVC

[Ilya Martynov]

> On Thu, 6 Jun 2002 20:15:24 -0600, Rob Nagler <[EMAIL PROTECTED]> said:

>> (http://sourceforge.net/projects/poop/).

RN> Great, another mailing list. :-)  Thanks.

It is not just mailing list. Don't miss
http://poop.sourceforge.net/. It has nice review of most Perl OO
persistence modules.

-- 
Ilya Martynov (http://martynov.org/)

Re: separating C from V in MVC

[Rob Nagler]

Andy Wardley writes:
> Yep, I agree.

Now we are getting somewhere. :-)

The issue here is not whether TT is a bad approach, but rather why the
syntax is not Perl.  It doesn't have to be, but you would save
yourself a lot of code and debugging.  In addition, there is more
opportunity for reuse if you can just say:

use Bla::Bla;

And, reuse test infrastructure, syntax-directed editors, etc.

Chris writes:
> Perl handels Regex's better than C, this is one of the reasons people use 
> Perl.

I disagree.  Perl's Regex processor is written in C.  The difference
is that it has outgrown Henry Spencer's regexp library.

> It makes (some) hard things easy and (some) impossible things 
> hard ... within it's domain. XSLT is no different. Use the appropriate tool 
> (or Toolkit) for the problem.

Agreed.  Perl is good at text manipulation.  It is imiho superior to
XSLT in all spaces which XSLT claims to solve.  Once you have an XML
parse tree in Perl, it's trivial to write a translator to any format
more correctly than XSLT.  My favorite example is XML to CSV.  Every
example I've seen in XSLT is cumbersome and wrong.  You'd think it
wouldn't be hard, but try it. ;-)

> existance beyond the Towers of Hanoi problem. But I haven't seen it solved 
> in TeX either (::know's there's gotta be a link for this::).

I'm sure Randall wrote a TeX to TT translator to generate his TT
version of ToH. ;-)

> Rob, is what you are suggesting that one should not use a turing complete 
> language for visual markup or that simply the language should be the best 
> match for the solution? I'm just looking for clarity on your position.

The question really surrounds "little languages".  Perl is ideally
suited to creating them.  There's no reason to invent a new syntax ([% %])
or semantics for standard structures.  I think you should write
classes in Perl that map to some interface which defines the language.

Here's another example, trimmed from our Integer.t:

Bivio::Test->unit([
'Bivio::Type::Integer' => [
get_min => -9,
get_precision => 9,
can_be_negative => 1,
from_literal => [
['9'] => [9],
['x'] => [undef, Bivio::TypeError->INTEGER],
[undef] => [undef],
],
],
]);

What does this do?  It "compiles" the list of tests and then executes
them.  It makes for very dense unit tests.  Perl's powerful
introspection mechanisms allow you to do this.

> benefit I have gained thus far from Perrin's eToys article (that and using 
> it to sell mod_perl to my superiors as a better solution than Java "eToys 
> delt with 10x these many customers ... I think our system can handle the 
> load").

It's pretty much gotten to the point where nobody gets fired for
choosing Java.  I've lost many contract bids because I didn't say Java
was the right solution.  I haven't lost a single customer who let us
solve the problem for them.

Perrin Harkins writes:
> In the companies I've worked for, it seems that political pressures 
> cause an HTML re-design every few months.

Weinberg strikes again: It's always the people problem...

> I also notice that bivio.com has a relatively clean and simple design. 
> If it were up to me, all "application" sites would have this kind of 
> simple design, but more often than not I seem to end up with designers 
> who are determined to take their interface cues from H R Giger prints.

Giger is awesome.  We need to work him into bivio.

A significant difference between our worlds may be that we're selling
a web-delivered application.  I'm guessing that your businesses were
more focused on selling products via the Web.

> (http://sourceforge.net/projects/poop/).

Great, another mailing list. :-)  Thanks.

Rob

Re: Separating Aspects (Re: separating C from V in MVC)

[Sam Tregar]

On Thu, 6 Jun 2002, Perrin Harkins wrote:

> For posterity, and possible inclusion in the next rev of the templating
> tutorial, how would you recommend people handle this sort of situation
> without using HTML::Template::Expr?
>
> Suppose you have a model object for a concert which includes a date.  On
> one page, the designers want to dipslay the date in a verbose way with
> the month spelled out, but on another they want it abbreviated and fixed
> length so that dates line up nicely.  Would you put that formatting in
> the controller?

In the script:

   $template->param(long_date  => $long_date,
short_date => $short_date);

In the template:

   The long date:   
   The short date: 

> What if you had a model object that generates a list of these concerts,
> and on a certain page the designers want to show it in two columns.
> Would you split it into two arrays in the controller?

I'm not sure I understand what you mean.  You're asking about how to flow
a list between two columns?  With vanilla HTML::Template that would
requrie a small amount of work in the script.  Either there would need to
be a column_break variable thrown in at the appropriate place or two
separate loops.  I think I would prefer the former.  In the template that
would look like:

  

 
 

  

In the script you'd just set the column_break in the appropriate row (or
rows for a multi-column layout).

Is that a point in favor of scripting in the templates?  Perhaps.  Of
course by limiting the power of template syntax I've made some things more
difficult.  If simple things should be simple and hard things should be
possible then not everything can be simple!

-sam

Re: Separating Aspects (Re: separating C from V in MVC)

[Perrin Harkins]

Sam Tregar wrote:
> Now, I don't use HTML::Template::Expr.  I think it's generally not such a
> good idea.  But it's there if you want it...

For posterity, and possible inclusion in the next rev of the templating 
tutorial, how would you recommend people handle this sort of situation 
without using HTML::Template::Expr?

Suppose you have a model object for a concert which includes a date.  On 
one page, the designers want to dipslay the date in a verbose way with 
the month spelled out, but on another they want it abbreviated and fixed 
length so that dates line up nicely.  Would you put that formatting in 
the controller?

What if you had a model object that generates a list of these concerts, 
and on a certain page the designers want to show it in two columns. 
Would you split it into two arrays in the controller?

- Perrin

Re: Separating Aspects (Re: separating C from V in MVC)

[wsheldah]

Ow. That philosophy of 'make it impossible for the programmer to mess up' sounds
too reminiscent of Pascal and other straightjacket development environments. I
don't think there's any real substitute for well-disciplined, thinking
programmers. So my own quest right now is to develop more of the right
disciplines, rather continue on some quest for a mythical Template System to End
All Template Systems or whatever.

For example, you mentioned you don't like objects in templates because they
introduce complexity. But others have already pointed out that objects can be
used in templates as simple read-only accessors by HTML designers who don't need
to know how the object is implemented. That's the great thing about
encapsulation. Sure this feature could be abused, but I'd rather err on the side
of freedom.

--Wes



Sam Tregar <[EMAIL PROTECTED]> on 06/05/2002 06:45:34 PM

To:   Andy Wardley <[EMAIL PROTECTED]>
cc:   modperl List <[EMAIL PROTECTED]>, Template
  Toolkit List <[EMAIL PROTECTED]> (bcc:
  Wesley Sheldahl/Lex/Lexmark)
Subject:  Re: Separating Aspects (Re: separating C from V in MVC)



Here's my theory: the best usage of most templating systems are virtually
indistinguishable and all result in reasonably maintainable systems.
However, the bad usage of some templating systems is much worse than
others.  Also, the general usage of a templating system, even by otherwise
bright people, tends more towards the bad than the good.

Thus my solution: a templating system that simply will not allow you to
put anything significantly complicated in the template.  You can't.  If
you want complexity you'll just have to put it in the code, where it
belongs.  That's HTML::Template in a nutshell.

>   [% silver.bullet %] isn't the answer by itself...

Here here.  Neither is  but I'd rather get shot
with mine than yours!

-sam

Re: separating C from V in MVC

[Andy Wardley]

On Thu, Jun 06, 2002 at 12:02:47AM -0600, Rob Nagler wrote:
> These are the reserve words of TT:
[...]
> Looks an awful lot like the same keywords in any general-purpose
> programming language.

Yep, I agree.  You can use it like a programming language and it 
gives you more than enough rope to hang yourself, or at least
get tangled around your feet and trip you up :-)

However, the way that I (mostly) use it, and the way that is encouraged
in the documentation, is to use it like a programming language only with
respect to presentation issues, not application issues.

For example, using a FOREACH to calculate some sum of values is probably
a Bad Thing, but using it to iterate over a data set and generate a 
table is a Good Thing.  It a presentation loop, not a programming loop.

Same goes for conditionals, and so on.  Even defining the equivalent
of functions or macros.  If it's something that generates a presentation
element and doesn't have any side effect on the application processing
or underlying model then I generally think it's OK.  Of course, it all 
depends on how you defined "presentation" and "programming".

But anyway, I'm not defending TT against HTML::Template or any other 
module because they admirably serve different purposes to different 
people at different times.

TT is most definately not an enforced pure template language.  You 
can use it that way if you like, but you can also use it as a quick,
dirty and butt-ugly hacking tool.  I construe that to be a good 
feature of a general purpose templating solution that TT aspires 
to be.  But I also readily admit that too much freedom to Do the 
Wrong Thing can be a weakness in particular environments.

That's why we have different modules.  Sometimes you need a hammer,
sometimes you need a saw, sometimes you need a socket set.  Sometimes
you use a wrench to bang in a nail because you can't find your hammer.
That's a useful feature of a wrench, even if it's not what it was 
designed to do.

> I think the rule is: if you can solve Towers of Hanoi in the language,
> its general purpose enough.  

Indeed.  And TT was designed to be general purpose enough to solve
the Towers of Hanoi.  I personally don't use it like that when I'm
building web sites, preferring to adopt a much more rigorous coding
standard, but there are also plenty of times when I do for small hacks.

> To solve this problem, we added a letter.  bOP is MVCF, where F stands
> for Facade.  

Yep, I'm doing something that's roughly similar.  Rather than have a
facade which presents a collection of backend objects, I'm building 
what is, I suppose, a composite built from a collection of backend
objects.  The way our data is structured seems to favour this approach
to my current way of thinking, but I will give the facade option some
more thought now that you've mentioned it.

But I think the concept is the same.  You have some object or data
structure which represents the collection of all the different 
components that combine to form one particular configuration of a 
site.  This is our site model, a separate entity from our MVC,
similar to your F.

> There are some basic design rules.  Eliminating redundancy is one of
> them.

Eliminating redundancy is another.  :-)

> I don't see how it is an "Aspect" (in the capital A sense).  

Only really in the sense that it's an orthogonal dimension in our
data space.  A degree of freedom, if you like.  Something that
cuts across a system but needs to be defined in one place (or 
plane).

> I suspect you'll find AOP won't be in heavy use in five years except
> for debugging features.  The magic of OO is hard enough to understand,
> and AOP is really magical.  AOP also doesn't solve very many
> problems.

I agree, but I found it useful in the way that it helped me to identify
and put a name on a common problem.  Once the lightbulb went on in my
head and I said "Oh, this is like the problem described in AOP" then 
it gave me a direction to tackle it.

> Why is there so little discussion of the M in MVC?  It's far from a
> trivial problem.

Indeed.

A

Re: separating C from V in MVC

[Rob Nagler]

Andy Wardley writes:
> Because Perl is a general purpose programming language.  TT implements
> a general purpose presentation language.  A different kettle of fish
> altogether.

These are the reserve words of TT:

GET CALL SET DEFAULT INSERT INCLUDE PROCESS WRAPPER 
IF UNLESS ELSE ELSIF FOR FOREACH WHILE SWITCH CASE
USE PLUGIN FILTER MACRO PERL RAWPERL BLOCK META
TRY THROW CATCH FINAL NEXT LAST BREAK RETURN STOP 
CLEAR TO STEP AND OR NOT MOD DIV END

Looks an awful lot like the same keywords in any general-purpose
programming language.

> It's like asking why XML has different syntax and semantics from
> Perl.

Well, if you read the XSLT spec and then look at an XSLT program,
you'll see a lot of verbosity and a lot of general purpose constructs
like variables, conditionals, and loops.  I haven't done much with
XSLT, but I do know you can get it in an infinite loop.  That seems
pretty general purpose to me.

I think the rule is: if you can solve Towers of Hanoi in the language,
its general purpose enough.  True formatting languages, such as,
Scribe do not contain general-purpose constructs, so you couldn't
solve the Towers of Hanoi.  HTML is another good example (ignoring

Re: Separating Aspects (Re: separating C from V in MVC)

[Sam Tregar]

On Wed, 5 Jun 2002, Andy Wardley wrote:

> In TT, you would usually pre-declare a particular format in a config
> file, pre-processed templates, or some other "global" style document.
> e.g.
>
>   [% USE money = format('%.02f') %]
>
> In your main page templates you would do something like this:
>
>   [% money(order.total) %]
>
> Then you can change the money format in one place and your designers
> don't have to worry about sprintf formats.

In HTML::Template::Expr:

  sub money { sprintf "%.02f", $_[0] }
  HTML::Template::Expr->register_function(money => \&money);

Then in the template:

  

Now, I don't use HTML::Template::Expr.  I think it's generally not such a
good idea.  But it's there if you want it...

> See, the problem is that MVC is just one particular decomposition.  It's
> generally a good one because application, data and presentation are typically
> the three biggest aspects that you want to separate.  However, it doesn't
> take into account any of the other dozen or so aspects that you might want
> to model in your system.  Nowhere in MVC or any other Design Pattern does
> it tell you to define all your URLs in one place in case you ever need to
> change them en masse.  You have to think of that all by yourself.  MVC is
> no substitute for thinking

Oh, absolutely.  MVC is just a framework, and it only addresses a subset
of the problems in any large system.  I think that's actually a strength.
I would be deeply suspicious of any paradigm that claimed to solve ALL my
problems.  I prefer small, simple (tools|paradigms) that do one thing and
do it well.

> I've seen far too many example of people who didn't pass objects into their
> templates, didn't embed Perl code, or didn't do this or that because they
> thought that it might violate the MVC principal.

Here!

> The end result was that they jumped through hoops and made the system
> more complex than it needed to be for the sake of "purity".

It was?  I don't think this is the only result.  It might be that these
people you've observed were just the hoop-jumping, complexifying types.
I've built quite a number of large systems without embedded Perl and object
variables without excessive hoop-jumping.

Here's my theory: the best usage of most templating systems are virtually
indistinguishable and all result in reasonably maintainable systems.
However, the bad usage of some templating systems is much worse than
others.  Also, the general usage of a templating system, even by otherwise
bright people, tends more towards the bad than the good.

Thus my solution: a templating system that simply will not allow you to
put anything significantly complicated in the template.  You can't.  If
you want complexity you'll just have to put it in the code, where it
belongs.  That's HTML::Template in a nutshell.

>   [% silver.bullet %] isn't the answer by itself...

Here here.  Neither is  but I'd rather get shot
with mine than yours!

-sam

Re: separating C from V in MVC

[Andy Wardley]

On Mon, Jun 03, 2002 at 09:49:59PM -0600, Rob Nagler wrote:
> Another concern I have about Template Toolkit (and other template
> languages) is that it has its own syntax and semantics for data and
> control structures distinct from Perl.  Why isn't Perl good enough?

Because Perl is a general purpose programming language.  TT implements
a general purpose presentation language.  A different kettle of fish
altogether.  

It's like asking why XML has different syntax and semantics from Perl.

> This is what Template Toolkit has become imo, and so the
> argument about template languages being "easier than Perl" is
> specious.  Rather, they become harder, because you have to think in
> two languages instead of one.

Perhaps, but I personally don't have any trouble switching between 
numerous different domain specific languages.  In the last hour, for
example, I've been using these: 

  Perl
  Perl regular expressions
  SQL
  XML 
  Javascript
  Template Toolkit

I find it easier to have a little language which is tailored to the task
at hand.  The problem comes when you try and grow your little language
into a general purpose programming language.  I've tried to resist that
temptation in TT, but I readily admit that feature creep is a common
trait in such systems.


A

Re: separating C from V in MVC

[Andy Wardley]

On Fri, May 31, 2002 at 12:21:45PM -0400, Jesse Erlbaum wrote:
> It's the "addition tricks" which bug me out.  With those two words you
> establish the mother of all slippery slopes to architecture oblivion.  

True.  And in your Perl code you can also write all sorts of dangerous code
that totally breaks your MVC architecture.  What stop you from doing that?

> IMHO, any system built on Template Toolkit (unless it is small and always
> managed by the same programmer) will ultimately devolve in just the same way
> as a Server Page system.

In my experience, that's not the case.  It will devolve just as fast as 
you allow it to.


A

Re: separating C from V in MVC

[Andy Wardley]

On Thu, May 30, 2002 at 05:42:23PM -0400, Jesse Erlbaum wrote:
> It has been my experience that applying a design pattern such as MVC is not
> a panacea.
[...]
> My point:  My
> code isn't good because I apply some "pattern" to it.  It may be good, and
> it may resemble a pattern -- but those two things are largely coincidental.

Absolutely!

> The View, in a web application, is really the HTML output.  Generally, this
> will be your templating system.  Optimally, the View avoids *ALL*
> application logic.  At my company we use HTML::Template because it strongly
> enforces the separation of View from Controller -- e.g., HTML from code.  (I
> realize that many of you prefer other HTML templating systems, but I still
> contend that HTML::Template is the most effective system for truly
> separating HTML from code.  And it's damn fast, too.)

Enforcing a clear separation of View from Controller is not the same thing
as not calling code from templates.  It is perhaps the most misunderstood
point about MVC and templates.

There's nothing wrong with calling a subroutine or object method from a 
template as long as:

  * the code perform a presentation function (not an application one)
  * the code doesn't have any side-effects on the model or other controllers

You can also call code to perform lazy data-loading as Perrin has already
mentioned, but that does require a little more thought on the part of your
back-end designers to ensure that things continue to behave as planned.

Or you can break all the rules if you know what you're doing.  I break
the rules all the time when I'm knocking together a few quick and dirty 
web pages, generating an SQL report, or a Postscript page showing a
graphical distribution of the first thousand prime numbers.  MVC is 
good for big web sites, but overkill for quick hacks.  

A

Re: separating C from V in MVC

[Andy Wardley]

On Mon, Jun 03, 2002 at 08:09:12AM -0600, Rob Nagler wrote:
> > [% FILTER font('my_first_name_font') %]
> > ... some text, possibly with other template directives in it...
> > [% END %]
> 
> One of the reasons Perl is popular is its idioms.  Having to say
> something in three lines is not as idiomatic as one line.  It takes a
> lot of discipline to use it everywhere.  In other words, I don't think
> the above is more comfortable than:
> 
> String(['User.first_name'], 'my_first_name_font');

So write it that way:

  [% String(user.first_name, my_first_name_font) %]

Just define the 'String' template variable to be a reference to your
'String' sub.

I do agree with what you're saying, however.  Perl is good, so don't
try and replace it with a markup language.


A

Separating Aspects (Re: separating C from V in MVC)

[Andy Wardley]

Continuing from the thread on the modperl mailing list:

On Sun, Jun 02, 2002 at 05:04:01PM -0400, Sam Tregar wrote:
> > I don't think the standard HTML::Template has support for formatting
> > numbers, dates, etc.
> 
> And thank the sweet lord it doesn't!  HTML::Template is a "do one thing
> and do it well" module.  If you want routines for formatting "numbers,
> dates, etc." then CPAN has just what you need.

I (mostly) consider formatting of numbers, etc., to be a presentation 
issue, not a programming one.  That's why TT supports this kind of 
thing in the templates (or in the code if you prefer).  

Of course, the fact that it's a module/object is entirely hidden.  TT 
abstracts the front end templates from the backend implementation, so
that the HTML designers don't have to know if a data structure is 
implemented as a hash, object, or subroutine, it just does the right 
thing.

This allows the developers to worry about implementing a back-end system
in the best way possible and the front-end designers to just use it.

> HTML::Template::Expr may present a solution to this particular desire,
> although it isn't one I've come across.  How often are HTML designers
> fiddling with numeric formats?  Are they really HTML designers if they can
> deal with, say, a printf-style format string?

In TT, you would usually pre-declare a particular format in a config
file, pre-processed templates, or some other "global" style document.
e.g.

  [% USE money = format('%.02f') %]

In your main page templates you would do something like this:

  [% money(order.total) %]

Then you can change the money format in one place and your designers
don't have to worry about sprintf formats.  

If you prefer to write your own formatting subroutine you can do it 
like so:

  my $vars = {
 money => sub { return sprintf("%.02f", shift) };
 order => {
 total => 22.95,
 }
  };

  $template->process($file, $vars) || die $template->error();

Guess what?  You don't have to change any of the templates.  They still 
use the same syntax:

  [% money(order.total) %]

This is abstraction.  Not to be confused with MVC which is one particular
architecture well suited to GUI applications.  Blindly applying MVC without
understanding the real issues (abstraction of front/back ends, separation of 
concerns, don't repeat yourself, etc.) is likely to build a system which is 
highly fragmented.  Maintenance becomes harder because everything is split 
up into many different pieces and it becomes difficult to see the wood for 
the trees.  

Aspect oriented programming teaches us that as soon as you decompose a 
system into a particular structure you inevitably fragments aspects which
cut across the system.  I have seen this in close and painful detail over the 
past few months while helping to build a very strictly partitioned MVC 
architecture system for Fotango(.com).  We're using TT for presentation, 
Openframe for the application pipeline/dispatch and a custom data backend 
called Vx.

Despite our best intentions, this web site doesn't neatly fall into 
clearly defined chunks of model, application and view.  Well, actually,
those parts do split down quite nicely.  But then you look at localisation,
for example, and we find there is localisation required in the data backend, 
localisation required in the applications and localisation required in the 
templates.  Thus, localisation is an aspect which cuts across the system.
By building a strict MVC we've fragmented localisation and have to trawl
through hundreds of different files to localise the site.  

Another example is that different countries running their localised versions
of this web site will want to change the URLs.  Where the english version
uses /product/shirt/red.html, the french version should instead be 
/produit/chemise/rouge.html, for example.  Again, these URLs are (currently)
embedded throughout the system and making any changes to them is a painful 
process involved many files spread across the M, the V and the C.  In an 
ideal world, English and French would just be different views of the same
model.  Alas, it's never that easy because the chances are that parts of
the model and parts of the controllers will also need changing.  

See, the problem is that MVC is just one particular decomposition.  It's 
generally a good one because application, data and presentation are typically
the three biggest aspects that you want to separate.  However, it doesn't
take into account any of the other dozen or so aspects that you might want
to model in your system.  Nowhere in MVC or any other Design Pattern does
it tell you to define all your URLs in one place in case you ever need to 
change them en masse.  You have to think of that all by yourself.  MVC is 
no substitute for thinking and it often encourages the opposite, lulling 
you into a false sense of security by the fact that you think you're doing 
the Right Thing.

I've seen far too many example of people who didn

Re: separating C from V in MVC

[John Siracusa]

On 6/4/02 12:32 PM, Perrin Harkins wrote:
> The thing that worries me about a widget approach is that I would have
> the same problem I had with CGI.pm's HTML widgets way back: the
> designers can't change the HTML easilly.  Getting perl developers out of
> the HTML business is my main reason for using templating.

My approach uses an intentionally limited subset of Mason as my "templating"
language.  It looks something like this:

* Model: Regular Perl classes and objects.

* Controller: Regular Perl classes and objects, trivially wrapped in Mason
components to control access location (i.e. URL), object caching, and so on.

* View: Mason components that receive "widget"-like objects as well as
simple strings and other params.

To try to solve the "designers don't know Perl" problem, I just constrain
the API usage of the widget objects for designers.  Example:


<% $form->field('name')->html_label %>
<% $form->field('name')->html_field %>


As concerned as I initially was by this syntax, the fact is that 99% of all
view objects have a series of exactly the same calls.  Designers have no
clue what they do internally, but the fact is that the only part that really
changes is the field name.  And there are very few, simple method names to
know: html_field, html_label, html_error, etc.  In the simplest case,
there's even a few places where this works:

<% $form->field('name')->html %>

And handles the label (if any), field, and field-tied error message all in
one block.  I guess the moral is that comfort != understanding.  Designers
can get comfortable with even "ugly" syntax like the above very quickly
since it is repeated so often.

Yes, this means that all the nuts and bolts of what gets printed by those
calls is handled by the controller object (which produces the widgets,
populating them according to the data form the model objects), and therefore
the programmer.  But IMO this is as it should be.  The programmer flags
which form fields are "required", what HTML surrounds "error messages"
(usually just ) and so on.  The designers change the
contents of the style sheets, make the graphics, and arrange the widgets on
the page.

And in a pinch, the programmer does have the full range of Mason features
available.  IMO, it's not much harder for designers to learn some small
subset of a larger syntax (like Mason/Perl-Widget-API) than it is for them
to learn an equal size subset (or entirety) of a "little language" like
template toolkit.

-John

Re: separating C from V in MVC

[Perrin Harkins]

Rob Nagler wrote:
> The way I understand how plugins work is that they are arbitrary
> classes.  But how do you share behavior?

I probably wouldn't use a plugin for something that needed to output 
HTML, because that would prevent the designers from editing it.  A macro 
(basically a mini-template) could be broken down into smaller shared 
templates, but there is a practical limit to that approach.

> FILTER does not shared behavior, but is a pipe mechanism.

Yes.  I think it would be a good way to do the FONT trick you mentioned 
though.

> There is no protocol for communicating between these various
> components except well-known global variables.

That's correct.  A template can call macros which are parameterized 
(e.g. a macro for making large text headlines which accepts the text as 
a parameter), but that's not exactly the same thing.  If you find that 
you really need to have stateful widgets that share data beyond whatever 
model data was passed to the view, then templating is probably not an 
appropriate solution.

> For example,
> if a Link is not executable by the current user, it won't render as a
> link (and possibly be completely blank depending on the circumstance
> and configuration).

That's easy to do, but not easy to share between multiple templates with 
different appearances.

> Another concern I have about Template Toolkit (and other template
> languages) is that it has its own syntax and semantics for data and
> control structures distinct from Perl.  Why isn't Perl good enough?

The syntax for accessing complex data structures in perl is non-trivial 
and possibly too confusing for designers.

Here's the perl version:
foreach my $account ( @{$model_data->{'user'}->{'accounts'}} ) {

and in TT:
[% FOREACH account = user.accounts %]
or with localized loop variables, like HTML::Template:
[% FOREACH user.accounts %]

> My experience with "little languages" is that they take on a life of
> their own

That can happen, and I've seen some people do appalling things with 
templating tools, but these people tend to be programmers working by 
themselves with no separate designer.  The place where these tools 
really pay off is when you're working with a separate design group.  My 
experience has been that designers have no trouble grasping the basic 
ideas of templating, and don't feel the need to try and wedge in stuff 
that doesn't belong there.

The thing that worries me about a widget approach is that I would have 
the same problem I had with CGI.pm's HTML widgets way back: the 
designers can't change the HTML easilly.  Getting perl developers out of 
the HTML business is my main reason for using templating.

- Perrin

Re: separating C from V in MVC

[Rob Nagler]

Perrin Harkins writes:
> I just didn't put in any fancy HTML in my example.  I could have put in 
> table tags right there, or made a macro if that table gets repeated a 
> lot.  Looks to me like they work the same.  In TT, I would probably use 
> macros or small templates (possibly defined in this same template file 
> at the top) for little repeating chunks, and filters or plugins for 
> things with more brains, like the String widget that decides whether or 
> not it needs to print FONT tags.

The way I understand how plugins work is that they are arbitrary
classes.  But how do you share behavior?

I couldn't find any protocol for sharing behavior in Template Toolkit.
FILTER does not shared behavior, but is a pipe mechanism.  PLUGIN can
only communicate through $context (global variables).  WRAPPER is
another form of FILTER.  INCLUDE, PROCESS, MACRO, and BLOCK are simple
textual substitution.  PERL is the same as a inline PLUGIN.

There is no protocol for communicating between these various
components except well-known global variables.  Yes, you could invent
a protocol, but it wouldn't be compatible with somebody else's
protocol.

Widgets can inherit behavior from other widgets.  For example, the
Enum widget is a subclass of String.  Enum overrides the render()
method, because it provides interesting behavior on enumerated types
in certain cases.  If the interesting behavior is not applicable, it
defers to String by calling $self->SUPER::render(@_).

We use inheritance quite a bit.  For example, CheckboxGrid and
RadioGrid inherit from Grid.  We have a ControlBase widget which
supplies the structure for boolean-controlled widgets.  For example,
if a Link is not executable by the current user, it won't render as a
link (and possibly be completely blank depending on the circumstance
and configuration).

Another concern I have about Template Toolkit (and other template
languages) is that it has its own syntax and semantics for data and
control structures distinct from Perl.  Why isn't Perl good enough?

The bOP view language implementation is about 100 lines of Perl (no
XS), and gives you all the power of Perl.  The Widget interface
contains three methods (new, initialize, and render), which provides
extensibility through Perl classes.  Variables are provided through
the WidgetValueSource which has two methods.  Finally, for "macros"
there are ViewShortcuts which are Perl subroutines collected in a
class (which usually inherits from other classes).  All of this is
plain old Perl.
 
My experience with "little languages" is that they take on a life of
their own, viz. Apache's configuration language and mod_rewrite.  They
become more and more complex until they become yet another programming
language.  This is what Template Toolkit has become imo, and so the
argument about template languages being "easier than Perl" is
specious.  Rather, they become harder, because you have to think in
two languages instead of one.

Just my $.02 or so... :-)

Rob