[Catalyst-dev] Opinionation

Sat Jul 8 11:06:22 CEST 2006

InstantApp sounds like a great idea.

I like what's in InstantCRUD and when I played with it I thought of some app
layer features that would be good to have. 

They could be built-in on top as optional parts.

1) Data dictionary

Admin screen to set up and edit the dictionary.

Keyed by partial field name and optional screen id. Looks up a field on a
screen. Look for first match from among: exact field + screen id, exact
field, field suffix. E.g. dictionary might have an entry for key and screen
id of ("media_id",""). Then field "bk_media_id" on screen "MD5" would match.
If you added an entry of ("bk_media_id","") that would override it. An entry
of ("bk_media_id","MD5") would override that again and be the most specific.

Gives label text, information on links to other screens, and preferred
display options, e.g. whether to show a date as a text input or calendar
picker, which can be passed into your screen renderer.

The renderer might know bk_slot_from_dt is of type datetime and have a
default screen element it uses for datetime. The dictionary display option
might change the behaviour for bk_slot_from_dt on all screens. A more
specific entry could override that for a particular screen id.

2) List screen pager class driven by list definition file

Defines some attributes and behaviours for a list, including top level
themed template to use, list of helper classes, information about the data
source (DBIx::Class Model), ordered list of column fields, list of
calculated fields (method names or anonymous coderefs), list of additional
info block methods to call/show between each display row, default search
criteria, primary and secondary search fields (secondary hidden in a
display:none until they click a show link to save space),

special search fields (methods or coderefs), any special search options
(profile code searches, free text searches).

List class runs off the list definition file and gives a fairly
sophisticated list interface with paging without the developer having to
know too much about the database model or screen renderer.

Admin screen which can query the data source to get lists of database fields
and allow user to change the fields to display, their order, set attributes
like heading title and theme.

I'm putting these two features into an app we're writing, maybe we could
mail you some samples when it's working properly?

I'd like to use a similar approach for a screen definition file at some
point. The reason for that is to make it easier for users to be able to
alter screen layout (through the app) and for novice developers to set up
and change apps.

Talking about the developer side, one problem I've found with perl and web
frameworks is that average programmers find it too much to learn and
remember (perl + framework classes + ORM classes) . They're much happier
working within a smaller problem space with some visual tools to help them. 

If I think back to using MS Access, Visual C++, VB, I think what worked well
was being able to

-          create default screens from a data model

-          integrated DB access; set screen properties for database fields

-          set screen element properties visually

-          preview screens with sample data from the data source

What didn't work well was:

-          VC++. One-off generation of class code. You'd do that, change the
db model later, then have to make a lot of code changes manually. That's
time consuming and error prone. Complicated framework.

-          VB. Hard-coded screen layout and fragmentation of code into
screen object event handlers which would become unmaintainable

-          Access. Data dictionary not fully integrated into screens, which
were generated on a one-off basis. Change the data model and you have to
manually find the inconsistent screens.

Much better to have a meta layer describing a screen and data source and
work with that using a visual tool.

Regards, Peter

 <http://www.dragonstaff.com/> http://www.dragonstaff.com  Business IT
Consultancy

  _____  

From: catalyst-dev-bounces at lists.rawmode.org
[mailto:catalyst-dev-bounces at lists.rawmode.org] On Behalf Of Zbigniew
Lukasiak
Sent: 07 July 2006 08:44
To: Development of the elegant MVC web framework
Subject: Re: [Catalyst-dev] Opinionation

Hi Brandon,

InstantCRUD is definitively evolving into the direction that you described
below.  As we add new features to it (like sessions, authentication,
authorisation) it is less and less InstantCRUD and I am thinking about
renaming it to InstantApp.  It has a replacement for catalyst.pl.  Currently
you need to specify all the inputs to it on the commandline - perhaps we can
turn it into a wizard but with wizards you still need to at least save the
chosen options somewhere so that the user does not need to go again and
again through the whole process when fixing some mistakes he did and that
makes it a bit complicated. 

--
Zbyszek

On 7/5/06, Brandon Black <blblack at gmail.com> wrote:

On 7/3/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> I think I might have finally figured out the answer:
>
> Catalyst has a One True Way.
>
> "Do whatever makes most sense within the design of *your* application"
>

Agreed here.  But to expand in a certain direction: I've always
pictured in my head that eventually Catalyst will gain a couple of new 
layers on top of the existing open-ended, flexible framework for
guiding new users into building apps with minimal effort along the
lines of the One True Way (and still making it easy for them, as they
become more advanced, to deviate from the One True Way as much as 
neccesary).

One of those layers could be the idea of an app-construction "wizard"
of sorts, like catalyst.pl on steroids.

"Do you need to support sessioning? [Yes]", "Do you need to support 
user authentication? [No]", etc ....  Importantly, this wizard forces
the user down the best practices path.  That means it does *not* ask
questions like "which view|orm|widget|ajax module?", only questions 
that are relevant to the (relatively unknowledgeable about the
Catalyst universe) user.

This wizard then does catalyst.pl + setting all the right plugins, and
sets up their basic config file with the right DSNs (and perhaps 
commented out examples for changing the config of some of the plugins
loaded), and even sets up a few new controllers aside from the
standard welcome page, which demonstrate the set of plugins in use and
how to use them properly. 

Its a somewhat tough project (not in coding terms, but more in design
terms), but I feel it could be a big win for the Cat community too.

You could of course take this idea to a whole new level by making a 
minimal Cat app implementation of the above wizard, and when the
wizard is done it cpan-downloads all the neccesary but missing plugins
into the app directory and overwrites itself with the new sample app.
Then the user can just "./cat- wizard.pl MyApp" (which creates the
wizard app at MyApp and fires up the built-in server on port 3000),
and walk through a web-wizard to tweak up his new application.

-- Brandon

_______________________________________________ 
Catalyst-dev mailing list
Catalyst-dev at lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev 

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst-dev/attachments/20060708/9bbd942d/attachment-0001.htm 