On 1/25/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Hello,
>
> One of the things we have decided to try and do for (likley) 1.3 is to
> have some basic customer relationship management. I have been thinking
> alot on this and have come up with some rough ideas on a model.
To me CRM includes g
Joshua D. Drake wrote:
>>> Joshua D. Drake
>>>
>> Would it be worth considering how SugarCRM or vtiger deal with
>> relationships as these seem to be the more popular of the OSS CRMS and
>> there have been numerous requests for integration tips over the years of SL.
>>
> Both are PHP based. Both
I've been watching both email groups SL for years and LSMB since its
inception. One item that keeps surfacing from time to time is the need for
some type of MRP module that can interface with either SL or LSMB.
I have over 11 years combined experience with manufacturing packages written
on the
>> Joshua D. Drake
>>
>
> Would it be worth considering how SugarCRM or vtiger deal with
> relationships as these seem to be the more popular of the OSS CRMS and
> there have been numerous requests for integration tips over the years of SL.
>
Both are PHP based. Both are ugly as all get out u
Joshua D. Drake wrote:
> Hello,
>
> One of the things we have decided to try and do for (likley) 1.3 is to
> have some basic customer relationship management. I have been thinking
> alot on this and have come up with some rough ideas on a model.
>
> company:
> +---
Hello,
One of the things we have decided to try and do for (likley) 1.3 is to
have some basic customer relationship management. I have been thinking
alot on this and have come up with some rough ideas on a model.
company:
+--+---
Chris,
> JMHO, of course, but so far everyone on the core team seems to agree.
> Chris Travers
To date, yes. The Pentabarf project has been doing some work on Rails to
make it integrate with more "intelligent" databases (stored procedures,
etc.) but the work is not complete. Also, since we al
Hi Ed;
I think you misunderstand the problem. I think we all welcome the
discussion, and this email is largely put together to help explain
where we are coming from so that the position makes a bit more sense.
It isn't that you can't do stored procedures via most ORM's but rather
that there are
On Thursday 25 January 2007 12:43, Joshua D. Drake wrote:
> I was walking through the tutorial and everything looked fairly
> reasonable until:
>
> # load from multiple namespaces.
> __PACKAGE__->load_classes({
> MyAppDB => [qw/Book BookAuthor Author/]
> });
>
> 1;
>
> Which i
Ed W wrote:
>> I fully understand your theory on frameworks. I use Django for a lot of
>> work.
>>
>
> OK, well as long as you tried one, that's all really...!
>
>
> *I* personally really dig the extra functionality that you get for free,
> but I'm definitely not going to try and persuade a
> I fully understand your theory on frameworks. I use Django for a lot of
> work.
>
OK, well as long as you tried one, that's all really...!
*I* personally really dig the extra functionality that you get for free,
but I'm definitely not going to try and persuade anyone to use one for
this
Ed W wrote:
> Hi
>
>> We are moving to a 90% SP model. Meaning that all data logic is going to
>> happen in stored procedures. ORMs, at least every one that I have seen
>> have no easy way to deal with using SPs.
>>
>
> Well, this is the only reason I keen harking on about the whole thing -
>
Hi
> We are moving to a 90% SP model. Meaning that all data logic is going to
> happen in stored procedures. ORMs, at least every one that I have seen
> have no easy way to deal with using SPs.
>
Well, this is the only reason I keen harking on about the whole thing -
I believe that you are in
Ed W wrote:
>> I wasn't talking about the MVC model, I was talking about the ORM. The
>> ORM is the problem here not the MVC model :)
>>
>
> What do you perceive is the problem with an ORM in this instance? Lets
> assume for a moment that we disregard very simplistic solutions which
> crudel
> I wasn't talking about the MVC model, I was talking about the ORM. The
> ORM is the problem here not the MVC model :)
>
What do you perceive is the problem with an ORM in this instance? Lets
assume for a moment that we disregard very simplistic solutions which
crudely map database rows to
Ed W wrote:
> Hi
>
>> You are correct, you don't have to use the ORM and you can break out of
>> it. But then why use it at all? It is reasonably simple (especially the
>> direction we are going) to just have a sane api that you don't have to
>> break out of.
>>
>
> Well, my point was that it'
Hi
> You are correct, you don't have to use the ORM and you can break out of
> it. But then why use it at all? It is reasonably simple (especially the
> direction we are going) to just have a sane api that you don't have to
> break out of.
>
Well, my point was that it's not really "breaking ou
Hi
> We are aware of this. However, we basically discovered that our
> design was basically a lightweight MVC anyway, and that a large and
> complex framework like Catalyst would add limited value and a lot of
> complexity. I suppose that as this develops, if there is a need to
> reconsider, we
18 matches
Mail list logo
