[Catalyst] Is Catalyst large enough to sustain a book?

Nilson Santos Figueiredo Junior acid06 at gmail.com
Sat Apr 29 05:15:17 CEST 2006


On 4/28/06, Yuval Kogman <nothingmuch at woobling.org> wrote:
> > You see, that's one of the issues. Frameworks should be consistent.
>
> That's your opinion. I'd rather my framework be flexible.

By default, be consistent. But don't factor out flexibility while
doing this. This is the ideal solution, IMO.

> Then it isn't a Catalyst book, it's a Catalyst/$that_ORM book

And probably be much more successful as a book (i.e. it will actually
get new developers and sales).

> Have you tried the other frameworks? They have much saner APIs IMHO.

I've taken a look at MochiKit and another really simple Ajax Framework
(whose name I can't recall). I didn't really like Mochikit, but since
I don't actually remember why maybe I should take a look at it once
again.

> Coding in Ajax.Updater and friends turned out to be a bit too
> flakey, underdocumented, untested and inconsistent for me.

I actually ended up not using Ajax.Updater except for really simple tasks.

But I don't really use Prototype because of its Ajax request methods
(although I no complains besides the Updater issues). I use it because
of the other stuff it provides. Its extensions to the base classes and
so on.

The problem with Prototype's documentation is that it's spread around
some 3 or 4 completely unrelated sites. But when you add it all
together, it's somewhat bearable.

> 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.

Right. I didn't quite grasp what you meant by "code generation". I
stupidly thought of something like Catalyst Helpers for .js files. ;-)

So bare with me.

-Nilson Santos F. Jr.



More information about the Catalyst mailing list