<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.6169" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><B>Hi Bill,</B></DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV><B>From:</B> <A title=moseley@hank.org href="mailto:moseley@hank.org">Bill
Moseley</A> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>On Tue, Jan 10, 2012 at 1:18 PM, Jason Galea <SPAN dir=ltr><<A
href="mailto:lists@eightdegrees.com.au">lists@eightdegrees.com.au</A>></SPAN>
wrote:<BR></DIV>
<DIV class=gmail_quote>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">hehe..
you want layers, I got layers..</BLOCKQUOTE>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>I just got out of yet another meeting about this architecture redesign.
(I'd like to see the graph that relates productivity to the number of
people involved some day...)</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>Jason, this is probably a question best for you and your experience, but
I (ignoring that graph above) would like to hear other's opinions and
reasoning.</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>My goal was to put a layer between Catalyst and DBIC for a few reasons,
including:</DIV>
<DIV>
<OL>
<LI>To have a place to put common model code that cannot be represented in
DBIC (e.g. data from other sources)
<LI>To be able to split up the model into logical units that can be tested
and used independently.
<LI>To abstract out the physical layout of the database -- be able to change
data layer w/o changing the API.</LI></OL></DIV><FONT face=Arial
size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote>
<DIV><FONT face=Arial size=2>I also needed that flexibility for exactly the
same reasons, but the "bad" thing is that Catalyst does so many things
automaticly and DBIC the same that it would imply a decrease in productivity
if the app would do those things. ...At least if the app is not very big and
complex.</FONT></DIV><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT><FONT face=Arial size=2></FONT>
<DIV><FONT face=Arial size=2></FONT><BR><FONT face=Arial size=2>Some actions,
like getting some records from a db, is surely the job of a model, but that
model could use records as simple hashrefs (as returned by DBI's
fetchrow_hashref), or it could use DBIC records, or other models could offer
the data with another structure. But there is no standard structure
defined for a model that should unify the data from more such models and offer
it to the view. I guess that it could be hard to define such a structure
because it would differ among different apps and it might also imply a
performance degradation.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>But some other actions are considered to be the
job of the controller, for example the authentication/authorization, or anyway
the job of the web framework, however sometimes that
authentication/authorization should be made in other ways, not by web, but by
a simple command line script, or by a GUI interface.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I guess that for beeing able to totally decouple
the web interface from the app, that app should offer a certain interface
which would be compatible with Catalyst and the developer would just need to
configure Catalyst part to handle the app foo at /foo, and another app bar to
/bar and another app baz to /.</FONT></DIV>
<DIV><FONT face=Arial size=2>And the interface of all those apps should accept
an authorization/authentication object with a standard format, and the
authentication should be made by Catalyst or the GUI app, or the CLI script...
And the apps used by Catalyst could offer their authentication/authorization
and the developer could configure Catalyst to use the authentication offered
by the app foo, or the app bar, or the app baz, or an external authenticator
that uses the database of another app, authenticator that should do the
validation and offer the authentication object in that standard format
accepted by the apps.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This way would be more simple to create adapters
for existing apps and combine them in a single web site, or change the
authentication...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Anyway, the question regarding the common format
of the data returned by the model to the view remains, and because it could
imply performance degrading to change the data structures returned by the
underlying modules, it might not be a good way. I am also thinking that there
are many developers that like the very limited style of other web frameworks
which accept a single ORM, a single templating system and don't even think to
decouple the app from the web framework...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Just thoughts.... Yeah I know, patches welcome.
:-)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>My idea was that Catalyst would call a method in the new model layer and
possibly get a DBIC object back. There is concern from some at my
meeting that we don't want to give the Catalyst app developer a "raw" DBIC
object and that we should wrap it (as it appears you are doing, Jason) in yet
another object. That is, we want to allow $user->first_name, but not
$user->search_related or $user->delete.</DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>That requires writing new wrapper classes for every possible result --
not just mirroring DBIC's result classes but possibly many more because the
new model might have multiple calls (with different access levels) for
fetching user data. That is, $user->email might work for some model
methods that return a user but not methods called on the model.</DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>Frankly, to me this seems like a lot of code and work and complexity just
to prevent another developer from doing something stupid -- which we cannot
prevent anyway. And smart programmers can get at whatever they want,
regardless. Seems more risky to make the code more complex and thus
harder to understand. The cost/benefit ratio just doesn't seem that
great.</DIV><FONT face=Arial size=2></FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>**</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>Yep, for not allowing the
developer to do something stupid, but also for making the application not
depend so much on the underlying model... DBIC for example.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>So if the team will decide to
change DBIC with something else, they should be able to continue to use
$user->email without changing the controller or the views.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>But in this model of work
(using fat models and thin controllers), most of the code is in the model
anyway, so no matter if the DBIC model or the business model would use the
biggest part of the code, changing DBIC with something else would imply a lot
of work if the new underlying module uses a totally different interface than
DBIC.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>So it becomes less important if
the developer would need to change just a few lines of code in the controller
or and/or templates.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>And this is theory, but I am
wondering how many times a team decided to change DBIC with another ORM or
another source/destination of data in practice.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>I guess that if they decide to
do that, it would be easier to rewrite the entire application.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>As I shown above, making an app
with the interface totally decoupled would be wonderful but this only if there
will be not much performance degradation which I doubt, and it should be also
a standard interface defined for Perl programs that should be largely
accepted, interface that will allow the developer to choose to publish it with
Catalyst, or with another web framework that will accept that interface, but
this will be complicated because that interface would depend on the app, would
be less flexible and might imply performance degradation.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV><FONT
face=Arial size=2></FONT><FONT face=Arial size=2></FONT></BLOCKQUOTE>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=gmail_quote><BR></DIV>
<DIV class=gmail_quote>Am I missing something?</DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT><BR></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT><BR></DIV>
<DIV class=gmail_quote>I suppose this is not unlike the many discussions about
what to pass to the view. Does the controller, for example, fetch a user
object and pull the data required for the view into a hash and then pass that
to the view? Or does the controller just fetch a user object and pass
that directly to the view to decide what needs to display?</DIV><FONT
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT></BLOCKQUOTE>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>***</FONT></DIV>
<DIV><FONT face=Arial size=2>As its name implies, the controller should
control things. So it should decide what should be presented, not the view.
The view should just present the data offered by the controller.</FONT></DIV>
<DIV><FONT face=Arial size=2>The view should not be able to present something
which is not allowed. But if many things are allowed, than the controller
could offer all those things and don't restrict the user object by creating
and offering another object which is more limited. The controller should be in
control even if that control is very limited sometimes.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote>I prefer just passing the object to the view. The
controller code is much cleaner and then when the view needs to change don't
need to also change the controller. And when there's a different view
(like an API or moble ) the same controller action can be used.</DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT><FONT face=Arial
size=2></FONT><BR> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>***</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>Yes, I also prefer that way,
because I usually don't need too many restrictions. But sometimes the view
should not get too much data, because the view could be say a WxPerl app which
is in a remote location, and it couldn't receive locally an object and execute
methods on it, but it should receive a serialized string, which shouldn't be
too big for a faster transfer, and in that case the controller should choose
to offer a smaller serialized object.</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial size=2></FONT> </DIV>
<DIV class=gmail_quote><FONT face=Arial size=2>Octavian</FONT></DIV>
<DIV class=gmail_quote><FONT face=Arial
size=2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>