On Monday, January 27, 2014 3:25 AM, Octavian Rasnita
<[email protected]> wrote:
From: "neil.lunn" <[email protected]>
> On 27/01/2014 1:27 PM, John Napiorkowski wrote:
>> Neil,
>>
>> I know the problem we have here, but honestly I think the solution is going
>> to be more about having less stuff in Catalyst.pm rather than more...
> Hi John,
>
> Actually probably missed something in my intended context in the course
> of the rant.
> Couldn't agree more with that statement, truly "less is more" and I
> wasn't putting a shout out to either change 'Catalyst::Helper' or
> otherwise bloat things in 'Catalyst Core'. So I think we can agree that
> it is better to pull things out and delegate to more "generic" "add-in's".
>
> I have seen in some reading terms and statements such as "monolithic
> catalyst application ...", which is sadly a sad misnomer and seems more
> of an indictment on the development model of the authors than an actual
> problem of Catalyst itself.
>
>> That said, it doesn't help today much :) Feel free to try a plugin and see
>> what people think. Is a good way to shakeout new ideas.
> So largely a position on "how many people are generally cargo culting
> the catalyst helper default files", which probably would have been a
> better title. And otherwise trying to get a feel for what other people
> were doing as typical, "App", "Controller", "View", "Model" setups.
>
> As for the code, that was my way of saying "here's one other way of
> doing it, what's yours?"
>
> If anything, the only critique here regarding the helper templates is
> that new inductees are likely to come on board and just so things as
> they are in the manual, without much thought to what is actually
> happening. Hence the reference to "getting logging set up under
> ConfigLoader", and so we show another approach. But not sure exactly
> what to do about making people think, and think differently, yet.
I think a better documentation for Catalyst *written by those who know the
internals very well* would be very helpful to solve this problem.
Too bad that those people don't have the necessary time for that.
I think the fact that Catalyst has too much magic is a reason why most
beginners prefer Dancer or Mojolicious.
Octavian
==JOHN
Ha, but I did try with this years catalyst advent to pull back the curtain, but
its never bad to say more. I think the key here is to focus on the good bits,
and try to make it better (the way we interface with PSGI and all that).
That said, if we move toward a version 6, I'd probably spend some time
discussing the general architecture and the design patterns around it.
Yeha, the helper templates are a bit long in the tooth. I'd actually prefer a
separate project for project builders, one that could be shared across
frameworks and that would make it easy for people to share project templates,
even on github for example. There's like 10 of these of CPAN but obviously
we've not hit the sweet spot yet, found the 'PSGI of project builders' since
everyone still does their own thing. Personally I just us bash myself. One
problem with the project builders is that it makes it easy to go to far and you
end up with complex bunch of stuff only you understand. my guess is that is
the core of the problem.
I personally don't have time for any of the helpers, but if someone stepped up
and wanted to modernize a bit I'd be happen to advise. Otherwise I do have a
side project for a project builder but not sure if its going to make sense for
others as it does for me,
John
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
