On Thu, 13 Jan 2005 10:52:21 + Dave wrote:
DS> > DS> It's simpler to understand the detail of each individual step,
DS> > DS> but it's much harder to understand how it all fits together.
DS> > DS>
DS> > DS> I think the existing model is much easier to understand, but needs
DS> > DS> more thoug
On Thu, 13 Jan 2005 09:38:13 + Dave wrote:
DS> Just out of interest, what was the reason for not regenerating
DS> the default-table-X.m2d file?
Not expecting it to be created ahead of time. If the file exists, I just read
it. If it didn't, I created it.
DS> RS> I know you have a low opinion o
On Wed, 2005-01-12 at 20:54, Robert Story wrote:
> DS> It's simpler to understand the detail of each individual step,
> DS> but it's much harder to understand how it all fits together.
> DS>
> DS> I think the existing model is much easier to understand, but needs
> DS> more thought as to the clos
DS> Just to check - this should also work if you start by creating a file
DS> default-table-X.m2d containing "@set $m2c_irreversible_commit=1@'
DS> and the generate the code (for the first time) - yes?
RS> Errr... yes. However, the disadvantage would be that if the
RS> default-table-X.m2d file exi
On Wed, 12 Jan 2005 10:02:53 + Dave wrote:
DS> Just to check - this should also work if you start by creating a file
DS> default-table-X.m2d containing "@set $m2c_irreversible_commit=1@'
DS> and the generate the code (for the first time) - yes?
Errr... yes. However, the disadvantage would be t
DS> But is there any way of generating such a [irreversible_commit] hook?
RS> Yes - it's a bit complicated at the moment. Probably should be made easier.
RS> You have to generate the code, then edit default-table-X.m2d and
RS> change the m2c_irreversible_commit flag to 1,
Aha!
That's the flag I
On Mon, 10 Jan 2005 15:02:41 + Dave wrote:
DS> > Yes. The idea is that eventually the agent will use the baby step modes,
DS> > and a helper will be created to map back for the old style modes.
DS>
DS> Hmmm I'm not sure I remember that decision. Or even the discussion
DS> that presumably
On Mon, 10 Jan 2005 15:02:38 + Dave wrote:
DS> > (A similar variable could control whether or not individual get, set,
DS> > validation and undo routines are generated. It would effectively move a
DS> > good bit of code out of the interface file and into the get/set files. ie
DS> > one big func
On Fri, 2005-01-07 at 16:29, Robert Story wrote:
> On Fri, 07 Jan 2005 10:34:45 + Dave wrote:
> DS> It appears that in most cases, the MfD framework effectively splits
> DS> each pass of the "traditional" SET handling model
>
> Yes. The idea is that eventually the agent will use the baby step
On Fri, 2005-01-07 at 16:29, Robert Story wrote:
> DS> The obvious oddity is the Commit handling - there's nothing
> DS> that works on committing individual columns.
>
> Correct. This is only because the tables I've dealt with all keep column data
> in the same place, so I haven't needed commits f
On Fri, 07 Jan 2005 10:34:45 + Dave wrote:
DS> It appears that in most cases, the MfD framework effectively splits
DS> each pass of the "traditional" SET handling model
Yes. The idea is that eventually the agent will use the baby step modes, and a
helper will be created to map back for the old
Robert,
as you know, I've recently been looking at the MfD framework,
and hence the baby_steps helper that it relies on. And I've got
a couple of question - mostly just requests for clarification.
It appears that in most cases, the MfD framework effectively splits
each pass of the "traditiona
12 matches
Mail list logo
