On Mar 8, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
> I understand what you're saying, and that depends on where you see
> dabo fitting in- for use by db/gui/3-Tier design beginners (like me)
> who may not know what they need to know to get things working, or
> where to start, or if it's targeting experienced developers who are
> experienced with DB design, rads, GUI frameworks, and just need a
> sensible toolkit.
> I'm hoping there's room to meet the needs of both groups ;-)
I'm targeting both experienced developers who know all this stuff,
as well as less experienced developers who are at least smart enough
to figure some stuff out on their own, and ask intelligent questions
about the rest.
>> mb = self._getMethodBase(mthd, None)
>> isEmpty = (txt.strip() == "") or (txt in mb)
>>
> Yay, something I fully understand.
Great! You could work on the Class Designer, then!
> Hmmm, I wonder what I did. I definitely had a situation last night
> where the editor had no visible text present (other than mb).
> My guess is I may have accidentally added some white space in the mb
> text- eg. (self)->( self), or similar. I'd never notice that. Or, an
> invisible control character? (Typing on the bus is not the most
> accurate in the world!)
The 'txt.strip()' should have taken care of those cases. Maybe you
had scrolled the content off of the visible screen?
>> You mean like http://paul.dabodev.com/doc/api/dabodoc/ ?
>>
> Yes (and I just discovered the link to the API docs this morning- what
> are you using to generate them?)
Paul handles that. I don't know how he does that.
> I think it'd be useful to have them available as a tarball, especially
> for those not blessed with always on high-speed interweb ;-)
I know that this idea has been proposed before. Perhaps when the
docs are generated, they are also gzipped and posted, sort of like we
do with the nightly tarballs of the code. Again, bug Paul about this.
> Erg, sorry, will try to be more clear.
> I've played a little with introspecting(? terminology) - eg using
> dir() on classes, modules, etc, and then looking at things inside
> them- such as docStrings.
> I was wondering if it would be relatively easy to import dabo,
> dabo.ui, in turn, and then go through them and pull out the docstrings
> for each item. Then this info could be displayed as a live tree of
> current API documentation, even with search functionality.
My problem with something like this is that having every single
thing documented is almost as useless as not having any - where do
you start? Knowing that dGrid has 8 zillion properties is great;
knowing which ones are especially useful - well, that's the key,
isn't it?
That's the idea behind the Property Sheet of the Class Designer:
only present the most commonly useful props in the editor. Yes, dGrid
does have a 'DynamicBorderLineStyle' property, but the chance that
you might ever need it is slim. And if your app is sophisticated
enough that you do need it, then you already know enough to figure
out how to set it.
>> Import statements are indeed included in the code file.
>>
> They weren't for me- ended up adding them by hand, until I added them
> to the 'managed imports' in the class editor source editor.
Oh, OK - that's what I meant. There is a place to place your import
statements so that they are available to all your code, and you found
it.
>>> e.g. dApp instance is in wrapper, so again, editors can't do full
>>> autocompletion
>>
>> Again, I'm not sure what you mean here.
>>
> I just bought wingware's IDE on the weekend, and I've been very
> impressed with it.
> There was something I was playing with in the generated code (sorry,
> now of course I can't remember what) for which it couldn't infer the
> type/couldn't provide completion hints.
> It was fixed when I manually added app=dabo.dApp() in the generated
> code file.
> Being curious, I wondered where this line was defined, and found it in
> the wrapper.
Again, I'm not sure what you mean by 'the wrapper'. dabo.dApp is a
regular Python class.
> Sorry, again, I didn't explain myself properly. I meant in the menus
> it'd be great if there was a save current xml file only, and not save
> the code. i.e. save, open, and revert do these operations on both the
> code and the layout at the same time.
> If I'm editing the code in an external editor, I want to re-load the
> code in dabo, but not the form definition.
> But again, it's not a big thing; I've learned to save everything in
> dabo, then save the code in wingIDE, then revert in dabo- this picks
> up the latest code & form definition quite nicely.
The link between the design objects and their code is probably the
thing about the Designer that I'm least satisfied with. When I first
created it I asked the readers of the list for their ideas on how to
improve it, and didn't get a single response. So if you want to take
a look at it and suggest a better approach, check out the 'code-ID'
attribute in the cdxml file.
Until then, I would be very loathe to treat the two as independent
entities. The bond between them is simply too fragile.
> Small suggestion; maybe there could be a GUI element that appears in
> this case that can display the original code for that method in the
> custom class (or opens the custom class), or at least indicates that
> there is some default behavior for this method.
Did you ever notice that little 'super' button in the code editor?
Ever wonder what that is for?
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
