Hi all;
After talking with Aurynn today, I think the following additional
restrictions need to be agreed to:
1) Our object structures need to be defined. I am going to propose
using Class::Struct for this.
2) We should agree that we are not passing whole $request objects
into the constructor.
On Mon, Mar 8, 2010 at 9:14 PM, Paul Wrightson wrote:
> mod_perl? Have you considered PSGI? Then - in theory - LSMB should be web
> server independent.
As long as we can get auth headers it will run on any web server,
perhaps with very minor modifications.
Best Wishes,
Chris Travers
--
t: [Ledger-smb-devel] Proposed Architecture Changes in 2.0 (Request for
comments)
Hi all;
Looking forward from 1.3, I am going to propose the following framework changes.
I think in general, the 1.3 framework is better than the 1.2 framework
in terms of understandable, testable code. Unfortunately
On Mon, Mar 8, 2010 at 4:21 PM, Adam Thompson wrote:
>> Regardless of where we automate such a transformation, I think it
>> would be helpful to automate it. Is there a specific objection to
>> automating the movement from a flat representation to a native
>> representation? Or do you think the
Chris Travers wrote:
>>> 3) Each database-based object should have a number of different
>>> constructors including one from a "flat representation," one that
>>> copies internal representation elements passed in the arg string, and
>>> one which retrieves from the database via the appropriate key
On Mon, Mar 8, 2010 at 10:32 AM, Aurynn Shaw wrote:
> Could you go into more detail on this? It sounds like we're talking
> about an automatic DB Model -> HTML Form translation layer.
I was actually thinking of a representation that allows something with
a flat representation (HTTP POST, maybe s
Hi;
>
> Looking forward from 1.3, I am going to propose the following framework
> changes.
>
> I think in general, the 1.3 framework is better than the 1.2 framework
> in terms of understandable, testable code. Unfortunately the
> framework isn't perfect and will run into a few issues on mod_perl
On Sun, Mar 7, 2010 at 4:18 PM, David F. Skoll wrote:
> Chris Travers wrote:
>
>> Given that our approach doesn't get to use some of the major parts of
>> a framework (authentication, model), and given that the view logic is
>> not likely to require much of a rewrite between 1.3 and 2.0, does
>> m
Chris Travers wrote:
> Given that our approach doesn't get to use some of the major parts of
> a framework (authentication, model), and given that the view logic is
> not likely to require much of a rewrite between 1.3 and 2.0, does
> moving to a pre-existing framework simplify or complicate our l
Kaare Rasmussen wrote:
>> Just to note what we get from being close to the db and letting it do
>> our authentication for us:
>
> Use Catalyst. It lets you do what you want. It only steps in where you need
> it.
+1
And the user community feels like the PostgreSQL and LedgerSMB do.
> Catalyst h
On Sun, Mar 7, 2010 at 6:37 AM, David F. Skoll wrote:
> Kaare Rasmussen wrote:
>
>> Use Catalyst. It lets you do what you want. It only steps in where you need
>> it.
>
> I'm not so sure about that recommendation. Having built some small
> projects with Catalyst, I found it fairly large and unwie
Kaare Rasmussen wrote:
> Use Catalyst. It lets you do what you want. It only steps in where you need
> it.
I'm not so sure about that recommendation. Having built some small
projects with Catalyst, I found it fairly large and unwieldy, quite
demanding of prerequisites and in a frustrating state
> Just to note what we get from being close to the db and letting it do
> our authentication for us:
Use Catalyst. It lets you do what you want. It only steps in where you need
it.
Catalyst handles M, V, and C as pluggable parts. You can even write your own
model layer, though most people want
Just to note what we get from being close to the db and letting it do
our authentication for us:
1) The business logic and security enforcement is centralized in the
db, so it can be accessed consistently through third party interfaces,
perhaps written in other languages. This reduces the possib
On Sat, Mar 6, 2010 at 6:39 PM, Armaghan Saqib wrote:
> On Sun, Mar 7, 2010 at 4:25 AM, Chris Travers wrote:
>> Looking forward from 1.3, I am going to propose the following framework
>> changes.
>
> Hi Chris,
>
> I am assuming that what you mean by 2.0 is a total rewrite. In that
> case we can
On Sat, Mar 6, 2010 at 6:40 PM, Armaghan Saqib wrote:
> On Sun, Mar 7, 2010 at 7:39 AM, Armaghan Saqib wrote:
>> I had a look at Jifty framework (jifty.org) few months ago for a new
>> custom work. Seems to be buzzword (ORB, MVC, REST) compliant and
>
> ORB -> ORM (typo)
And I was getting excite
On Sun, Mar 7, 2010 at 7:39 AM, Armaghan Saqib wrote:
> I had a look at Jifty framework (jifty.org) few months ago for a new
> custom work. Seems to be buzzword (ORB, MVC, REST) compliant and
ORB -> ORM (typo)
Regards
Armaghan
- Sql-Ledger hosting, docs and development
- http://www.ledger123.co
On Sun, Mar 7, 2010 at 4:25 AM, Chris Travers wrote:
> Looking forward from 1.3, I am going to propose the following framework
> changes.
Hi Chris,
I am assuming that what you mean by 2.0 is a total rewrite. In that
case we can freely choose some existing framework.
I had a look at Jifty frame
On Sat, Mar 6, 2010 at 3:43 PM, Luke wrote:
> On Sat, 6 Mar 2010, Chris Travers wrote:
>
>> 6) Workflow scripts will allow stacks of coderefs to be pushed onto
>> before, instead, and after piles, allowing for shims to be placed by
>> system integrators at these points.
>
> Interesting statement,
On Sat, 6 Mar 2010, Chris Travers wrote:
> 6) Workflow scripts will allow stacks of coderefs to be pushed onto
> before, instead, and after piles, allowing for shims to be placed by
> system integrators at these points.
Interesting statement, perhaps only because I am used to thinking about
thi
Hi all;
Looking forward from 1.3, I am going to propose the following framework changes.
I think in general, the 1.3 framework is better than the 1.2 framework
in terms of understandable, testable code. Unfortunately the
framework isn't perfect and will run into a few issues on mod_perl,
coding
21 matches
Mail list logo
