In VFP had a rule, never work with VFP objects directly, should always
generate libraries of classes based on the objects of VFP
(CommandButtons, labels, grids, page frames, etc). This mode is also
recommended working with Dabo? (dlabel, dBitmapButton, dGrid, etc)?, If
the answer is yes, as would be the best way to implement it? , Such that
the classes create folders, etc?
Thanks for the suggestion
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/jj5coc$rdo$1@dough.gmane.org
On Tuesday, March 06, 2012 11:07:33 AM STyler wrote:
> This mode is also
> recommended working with Dabo?
I don't think so! I use Dabo controls directly all the time. There are times
I have created sub-classes for a few special reasons. But generally I use
Dabo's classes.
Johnf
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/3701991.RInR1GvCj9@linux-12
On Mar 6, 2012, at 8:33, John Fabiani <johnf@jfcomputer.com> wrote:
> On Tuesday, March 06, 2012 11:07:33 AM STyler wrote:
>> This mode is also
>> recommended working with Dabo?
>
> I don't think so! I use Dabo controls directly all the time. There are times
> I have created sub-classes for a few special reasons.
It probably depends on how easy it is to refactor your class. In vfp it was a pita to change what class an instance was based on, and frequently the behavior of the base classes just wasn't ideal and the only way to override was to subclass. These concerns still exist in dabo but to a much lesser degree.
I frequently just instantiate dabo vase classes but when I need more than one instance to have the same specialized behavior I'll then take the opportunity to refactor that into a common base class.
It is really up to you.
Paul
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/F908DF4D-AF20-40C3-BA90-10978C6A72BF@ulmcnett.com
On Mar 6, 2012, at 10:55 AM, Paul McNett wrote:
> It probably depends on how easy it is to refactor your class. In vfp it was a pita to change what class an instance was based on, and frequently the behavior of the base classes just wasn't ideal and the only way to override was to subclass. These concerns still exist in dabo but to a much lesser degree.
The only reason I can see for this is if you need a distinct behavior for some particular class in your application. E.g., you want all textboxes to use a certain font, or have forms with a blue base panel, etc. In those cases, you would just make a subclass that had that behavior, and then use that subclass in your app.
-- Ed Leafe
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/B6310BF6-3058-4AD6-BC4B-F7BE8FE8E655@leafe.com
On 3/6/12 11:18 AM, Ed Leafe wrote:
> On Mar 6, 2012, at 10:55 AM, Paul McNett wrote:
>
>> > It probably depends on how easy it is to refactor your class. In vfp it was a pita to change what class an instance was based on, and frequently the behavior of the base classes just wasn't ideal and the only way to override was to subclass. These concerns still exist in dabo but to a much lesser degree.
> The only reason I can see for this is if you need a distinct behavior for some particular class in your application. E.g., you want all textboxes to use a certain font, or have forms with a blue base panel, etc. In those cases, you would just make a subclass that had that behavior, and then use that subclass in your app.
The examples you cite do not, in and of themselves, suggest making a subclass in
Dabo, although they sure did in VFP. Here's what I tend to do in Dabo:
{{{
lblFontProps = {"FontSize": 9, "FontBold": True}
ctrlFontProps = {"FontSize": 10}
dataCtrlProps = {"DataSource": self.Form.PrimaryBizobj.DataSource}.update(ctrlFontProps)
...
hs = dabo.ui.dSizer("h")
hs.append(dabo.ui.dLabel(self, Caption="Heh:", **lblFontProps))
hs.append(dabo.ui.dTextBox(self, DataField="name", **dataCtrlProps))
self.Sizer.append(hs)
...
}}}
But I do make composite controls sometimes, which usually involve 2 or more controls
inside a dPanel. The way the controls interact are contained inside methods in the
dPanel subclass. Subclassing dPanel makes sense to me in this case.
Paul
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/4F566525.4020108@ulmcnett.com
On Mar 6, 2012, at 1:27 PM, Paul McNett wrote:
> The examples you cite do not, in and of themselves, suggest making a subclass in
> Dabo, although they sure did in VFP.
While it's certainly easier to do in Dabo, I tend to be lazy. If I have to add dozens of controls with the same changes across many forms, I'd rather define the subclass once and then use that in all my forms.
> hs.append(dabo.ui.dTextBox(self, DataField="name", **dataCtrlProps))
I prefer the properties parameter rather than the ** form:
hs.append(dabo.ui.dTextBox(self, DataField="name", properties=dataCtrlProps))
They both work the same, but that's what that parameter was created for.
-- Ed Leafe
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/7E31BCA8-79CA-4B08-B874-5DD47863164C@leafe.com
On Tuesday, March 06, 2012 01:48:26 PM Ed Leafe wrote:
> On Mar 6, 2012, at 1:27 PM, Paul McNett wrote:
> > The examples you cite do not, in and of themselves, suggest making a
> > subclass in Dabo, although they sure did in VFP.
>
> While it's certainly easier to do in Dabo, I tend to be lazy. If I have to
> add dozens of controls with the same changes across many forms, I'd rather
> define the subclass once and then use that in all my forms.
> > hs.append(dabo.ui.dTextBox(self, DataField="name", **dataCtrlProps))
>
> I prefer the properties parameter rather than the ** form:
>
> hs.append(dabo.ui.dTextBox(self, DataField="name",
> properties=dataCtrlProps))
>
> They both work the same, but that's what that parameter was created for.
>
>
>
> -- Ed Leafe
STyler,
Just reading the answers should tell you a lot.
Ed's way still uses the base class but changes the properties. Sounds like he
was concerned with maintaining a consistent UI.
Sound's like Paul's situation is different where he needed a special action to
occur - so he built a special sub-class of two (maybe more) base class
controls - but still uses Dabo base classes.
In my case I too required a special action associated with a Dabo base class.
Just proves that Dabo's base classes are flexible and usable for most cases.
Johnf
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/5973533.DkCP9fEona@linux-12
Thank you all for your comments, I will work with sub-classes.
Greetings.
El 06/03/2012 03:40 p.m., John Fabiani escribió:
> Just reading the answers should tell you a lot.
>
> Ed's way still uses the base class but changes the properties. Sounds like he
> was concerned with maintaining a consistent UI.
>
> Sound's like Paul's situation is different where he needed a special action to
> occur - so he built a special sub-class of two (maybe more) base class
> controls - but still uses Dabo base classes.
>
> In my case I too required a special action associated with a Dabo base class.
>
> Just proves that Dabo's base classes are flexible and usable for most cases.
>
> Johnf
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/jj7ute$sko$1@dough.gmane.org
On 3/6/12 11:48 AM, Ed Leafe wrote:
> On Mar 6, 2012, at 1:27 PM, Paul McNett wrote:
>
>> The examples you cite do not, in and of themselves, suggest making a subclass in
>> Dabo, although they sure did in VFP.
>
> While it's certainly easier to do in Dabo, I tend to be lazy. If I have to add dozens of controls with the same changes across many forms, I'd rather define the subclass once and then use that in all my forms.
True, I do that as well. The point being, in Python/Dabo it is so much easier to
refactor your class structure after the fact that you may as well do the simplest
thing that will work at the time, rather than doing all the thinking ahead that was
commonplace in VFP development.
So when crafting a form, start out using the Dabo base classes. Then if you find
yourself setting the same properties over and over again, you have a candidate for a
small or large refactor. I'm constantly refactoring stuff in my codebase because,
like Ed, I'm lazy when I'm heads-down developing something for the first time getting
it to work. But later on, maybe months or even years later, when I'm revisiting to
add something anyway, I'll spend 15 minutes reading the code and refactoring the
obvious things.
>> hs.append(dabo.ui.dTextBox(self, DataField="name", **dataCtrlProps))
>
> I prefer the properties parameter rather than the ** form:
>
> hs.append(dabo.ui.dTextBox(self, DataField="name", properties=dataCtrlProps))
>
> They both work the same, but that's what that parameter was created for.
I prefer the ** way because it is more Pythonic, shorter to write, and easier to
immediately understand.
Paul
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/4F578E69.2070809@ulmcnett.com
On Wednesday, March 07, 2012 08:35:53 AM Paul McNett wrote:
> I prefer the ** way because it is more Pythonic, shorter to write, and
> easier to immediately understand.
Yes easier to understand - but harder to follow. When I review my code where
I have used **kargs I always have to remind my self what is in the simple
call. And of course if you are over loading a class then you have to check
for the values.
Johnf
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/60508497.MH86qlJKdo@linux-12