|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Advice for Web Application Framework
|
If you like django, check out http://pinaxproject.com/
It builds on top of django and has a lot of common infrastructure
ready to go. It hasn't hit 1.0 yet, but it's shaping up to be quite
nice.
On Tue, Jan 5, 2010 at 8:29 AM, Gordon Dexter <gordon@texasdex.com> wrote:
> I used Django as well, and liked it. Managed to make a simple web app
> pretty quickly, and next time around I'll be able to make something
> complicated, pretty quickly, since I know how it works now. If you're a
> fan of the MVC paradigm, Django's a good way to go.
>
> --Gordon
>
> Mag Gam wrote:
>> starting to use Django and its really nice.
>>
>> On Tue, Jan 5, 2010 at 2:42 AM, Chaz Meyers <plug@thechaz.net> wrote:
>>
>>> On Mon, Jan 4, 2010 at 9:11 PM, John Karr <brainbuz@brainbuz.org> wrote:
>>>
>>>> I'm starting development on a web based data application. Since this will be
>>>> a fairly large application I would like to select a Framework (ie Django,
>>>> Ruby on Rails, Catalyst) or collection of libraries/modules so that I can
>>>> focus on logic and functionality.
>>>>
>>> If you want to stick with Perl but don't have much programming
>>> experience, I recommend looking at CGI::Application.
>>>
>>> Catalyst is awesome and I believe has a larger community surrounding
>>> it, but it takes advantage of programming concepts and Perl syntax
>>> which may not be familiar to you, so there might be a steeper learning
>>> curve.
>>>
>>> In contrast, in your usual C::A webapp you're just writing a fairly
>>> straightforward class. It's pretty transparent what's going on, and
>>> CGI/Application.pm is fairly understandable to read for someone even
>>> with a little Perl OOP experience. As you become more experienced,
>>> you have the option of adding more advanced functionality like hooks
>>> and plugins, but none of those are needed when you're getting started.
>>>
>>>
>>>> I plan to take advantage of the fact
>>>> that Postgres supports writing Stored Procedures in PERL to move logic from
>>>> the front-end to the database, which further supports PERL as first choice
>>>> and Python (which is also supported by PostGres) as second choice.
>>>>
>>> I don't know your exact situation so this bit may be completely
>>> irrelevant to you. If you have multiple applications touching the
>>> database, stored procedures can help a lot to eliminate duplication of
>>> logic and ensure data integrity.
>>>
>>> However, if your database is just acting as a data store for your
>>> webapp and you know for a fact that no other application will ever
>>> touch your database directly, it might be smart to keep as much of
>>> your logic in your application as you can. Web nodes are very easy to
>>> scale to multiple machines. Throw a reverse proxy in front of a bunch
>>> of web nodes, and as long as they're not writing session data to disk
>>> you're set. Scaling to a second database machine can be much more
>>> tricky.
>>>
>>> - Chaz Meyers
>
> ___________________________________________________________________________
> Philadelphia Linux Users Group -- http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
>
--
J.
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|