Uwe Grauer wrote:
> Carl Karsten wrote:
>> Ed Leafe wrote:
>>> On Jan 4, 2007, at 4:30 PM, Carl Karsten wrote:
>>>
>>>> How about keeping the class code in the cdxml, which will promote
>>>> the "event's
>>>> call methods" practice: the .hit code in the cdxml will just be
>>>> something.ImHit() in some module that can be edited with my
>>>> favorite editor?
>>> Does your editor properly handle Python code within XML? Does it
>>> know to switch syntax coloring and block comment style when you move
>>> from an XML section to Python code in a CDATA section?
>> "in some module that can be edited" is a normal .py file, not the xml. so
>> yes,
>> it handles all the xml just fine. :)
>>
>> Now that I think about it can see it being attribute driven, so no code in
>> the
>> cdxml at all.
>>
>>> the overwhelming choice of users is to keep the Python
>>> code in a separate file.
>> right - keep the python code in one file and the layout in the cdxml.
>>
>>> Of course, that's something you can
>>> configure for yourself (Menu: File/Single File for Layout and Code)
>> There isn't any backwards compatability issues, right? dump that option and
>> the
>> code editor window all together. make your life simpler.
>>
>
> Why? Some people might prefer to only use the IDE instead of their
> favorite editor.
Why: Less work for Ed.
given "overwhelming choice of users" I am wondering if anyone wants to only use
the IDE.
you say "Some people might" which makes me think you don't even want it.
>
>>>> There shouldn't be lots of code in the UI anyway, right?
>>> There should be as much as is needed.
>> I suggest none is needed.
>>
>>> Look as the ClassDesigner*.py
>>> files: they are 100% UI code. Is that too much?
>> We must have a different idea of what UI code is.
>>
>> to me, this is not UI:
>>
>> xml = xtd.dicttoxml(propDict)
>> # Try opening the file. If it is read-only, it will raise an
>> # IOError that the calling method can catch.
>> open(clsFile, "wb").write(xml)
>>
>> so maybe UI isn't a good term to use. How about skin?
>
> Layout and code! (You said it.)
layout and code works for me.
>
>> To me, this is mostly skin: ClassDesignerMenu.py - When I look at it (the
>> file)
>> I can get a feel for what I will see when it runs, but no idea what will
>> actually happens when I start interacting with it (other than what I can
>> infer
>> from the method names.) It is more of a config file written in code. I can
>> see
>> that being replaced by a cdxml and a loader. In witch case, the cdxml
>> editor
>> doesn't need to edit any code.
>>
>> ClassDesignerMenu.py has this line:
>>
>> itm = fm.prepend(_("Save as C&lass\tCtrl+Shift+S"),
>> bindfunc=app.onSaveClassDesign, help=_("Save the ClassDesigner contents as a
>> class"))
>>
>> which calls the .write() code from ClassDesignerFormMixin.py. That file
>> contains no skin. I don't see anything that could be edited with a visual
>> GUI
>> editor like the class designer.
>>
>> So nice separation of skin from ... bones.
>>
>> I am guessing this is how you normally write code. or at least consider it
>> a
>> good practice, right?
>>
>> Carl K
>>
>
> If you look at boa-constructor you can see that they wrote layout-code
> and user-defined code in one file.
> This is sometimes more complicated as the dabo way seperating layout and
> code in different files (as Ed teached me).
I am missing your point, unless you are supporting separate layout and code.
Carl K
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
