Re: [Catalyst] thoughts on a catalyst roadmap

[Bill Moseley]

On Thu, Oct 11, 2012 at 8:04 AM, John Napiorkowski wrote:

>
>
> http://jjnapiorkowski.typepad.com/modern-perl/2012/10/thoughts-on-a-catalyst-roadmap-1.html
>


I tend to describe Catalyst as glorified dispatcher and object instance
manager.   The goal there is to make people think about thin controllers
and lots of models.   Controller bloat tends to happen if not careful.

Plugins are big, but looking at our apps we probably use more custom
plugins than CPAN ones.  Granted, mostly CPAN inspired but end up
customizing for our own needs.

Obviously, being able to easily hook into the request process is huge.

I agree with your thoughts about REST and web sockets.  Much (most?) of our
development is REST based.  I've written two REST replacement systems now
(Controller base class and Action class).  One is very similar to
Catalyst::Action::Rest, but much more heavy weight with CRUD and a bit of
magic built in, and another rather light weight based on chaining.

Views are becoming less important/interesting since more of that is
client-side and much is just returned as JSON.

Pain points I have are around scalability.   I'd like to have our "app" be
made up of many small apps because dev on a very large app can get slow.
Having separate apps isn't too hard, although it's a bit more of a pain for
rendering templates and sharing a standard layout across separate apps.

I've also been looking at ways to manage features -- or really a way to
control features dynamically.   In other words, all developers work adding
features in trunk and always release from trunk.  And have a way to
dynamically turn features on or off -- or on to just a sub-set of
accounts/IP addresses/etc.   That's mostly looking for ways to make the
build, test, release process less painful -- and less expensive.   And
releases more frequent and less anxious.



-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] thoughts on a catalyst roadmap

[Octavian Rasnita]

Hi,

From: John Napiorkowski 


  Hey All,


  I published a blog regarding my thought (and only my thoughts at this point) 
regarding how to approach understanding what a long term roadmap for Catalyst 
could be.  From the recent poll it seems this is a major gap.  So here's my way 
to kick off a conversation, and I'm sharing linkage here on the list since I 
know not all of you hang on on IRC or follow a lot of blogs:


  
http://jjnapiorkowski.typepad.com/modern-perl/2012/10/thoughts-on-a-catalyst-roadmap-1.html



  Thanks!


  John






  I think that it could be helpful if that roadmap would tell more clear for 
what kind of web sites would be Catalyst better than other frameworks (and for 
what kind of sites would not be).

  For example, I think that Catalyst is good for big web sites as well as for 
small sites, but in case of limited resources, especially memory, Catalyst 
might not be the best choice, and because the apps made with Catalyst usually 
have many dependencies, it might not be the best choice when the app is 
deployed on the cloud. Or am I wrong? It would be helpful to be sure...



  Then, in order to find where is Catalyst on his road, it can be positioned in 
comparison with other web frameworks (especially Dancer and Mojolicious, but 
maybe even frameworks for other languages, like Ruby on Rails).



  I've seen that some newbies use to put questions about the recommended web 
framework on some sites (like Linkedin) and I think that it could be helpful 
for them if they could see the most important differences between most 
important frameworks without needing to learn them all before beeng able to 
decide.

  And the things that can be compared could be... if the framework has 
scafolding scripts, if they use a single file or more, how scalable they are, 
if they need a manual URL dispatcher or if it is done automaticly, if they can 
be used on some cloud sites or not, how easy is to use other modules from CPAN 
with them, like DBIC, TT, HTML::FormFu, or Rest, or how easy is to integrate 
Catalyst apps with other existing apps... and which are the proposed 
improvements where they are necessary.

  Also some things about using Catalyst and Bread::Board in the future and how 
it be useful would be also helpful.



  The recommendation is to create Catalyst apps as standalone as possible and 
to use the web just as an interface... one of the interfaces of the app, but 
most of the tutorials and examples are not done this way.

  It would be also helpful to know if there are intentions to make Catalyst to 
be even more easier to use with such a standalone app, and how should be the 
interface offered by that app to work with Catalyst I mean, if some best 
practices should be expected, or TIMTOWTDI (each on his own) will be the single 
recommendation in the future.



  Octavian


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/