[Catalyst] Is Catalyst large enough to sustain a book?
nothingmuch at woobling.org
Fri Apr 28 18:32:03 CEST 2006
On Fri, Apr 28, 2006 at 14:19:36 -0300, Nilson Santos Figueiredo Junior wrote:
> On 4/28/06, Yuval Kogman <nothingmuch at woobling.org> wrote:
> > That's DBIC's job - while it can be coverred e.g. under a hybrid
> > Catalyst and DBIx::Class book, a Catalyst book on it's own should
> > not really consider this a show stopper.
> You see, that's one of the issues. Frameworks should be consistent.
That's your opinion. I'd rather my framework be flexible.
*The* reason I liked catalyst so much back in my first usage was
because the website I wrote then had nothing to do with a DB.
Subsequently Class::DBI exploded, and Catalyst survived.
I am confident that this is the superiod approach.
> A Catalyst book should adhere to a single ORM. Of course it should
> also state that Catalyst is flexible and that other ORMs are
> available, etc.
Then it isn't a Catalyst book, it's a Catalyst/$that_ORM book
> > HTML::Prototype is a direct port of the rails api - which sucks.
> It's not a direct port. Not everything is available and in TT you
> still have to do something like p.method() instead of just method().
Catalyst::View::TT::FunctionGenerator was written exactly for that purpose.
> > Frankly, I think Prototype/scriptaculous kinda sucks, after having
> > used it - it's fun, till it has to scale a bit more.
> I disagree.
> ever happened since sliced bread.
Have you tried the other frameworks? They have much saner APIs IMHO.
Coding in Ajax.Updater and friends turned out to be a bit too
flakey, underdocumented, untested and inconsistent for me.
> Scriptaculous is a nice library built on top of Prototype. I mainly
> use it for the Effects library and some other neat extensions. But,
> although not awesome, it's far from sucking.
Scriptaculous was ported to most the other toolkits. It's nice to
have some pre-cooked effects and stuff, but when the going gets
tough and you need heavyweight things, like tree expansion, sub
widgets, deep validation, various progress indicators, error
reporting things, and so forth, Prototype/Scriptaculous is no better
than any other toolkit, and in many people's opinion far worse due
to lack of proper documentation / testing.
By far the biggest weakness of Prototype is the Updater - the API is
just not generic enough for heavy weight things - any transfer of
data that is more complex than .innerHTML becomes a burdon.
> > Usually code generation is fun but then limiting - which is expected
> > and OK (since after all you are writing in a pretty high level
> > programming language), but the moment that you start doing prototype
> > "by hand" it's weaknesses start to show their ugly head.
> Hmm... I must be somewhat unware of these things, because I've never
> seen JS code generation. Unless you mean that evaled <script></script>
> weirdness of Rails (which, although weird, can be useful, but is not
The prototype bindings *ARE* code generation. What do you think
link_to_remote does? it simply generates an <a href> that talks to a
some JS code that eventually runs Ajax.Updater with the said URI,
updating the appropriate DIV.
> It's a small but really, really nice feature. Not a paragon of
> maintainability for traditional applications, but great for speeding
> up small tasks. And you're coding an AJAX application these sure do
> add up.
> It's somewhat analogous to that "flash" RoR thingy, which
> C::P::Session borrowed. It seems completely useless and idiotic, until
> you start using it. It simplifies small, day-to-day annoyances.
FYI I wrote most of the code for both, you don't need to convince me
Yuval Kogman <nothingmuch at woobling.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060428/4474b81d/attachment.pgp
More information about the Catalyst