[Dev] XML for CPIA

[Brendan O'Connor]

On Aug 10, 2005, at 11:25 AM, Bryan Stearns wrote:





> I'm looking forward to declaring UI elements in Python because  
> Python is much more flexible and concise  than XML. For instance,  
> if you look at the detail view's parcel.xml today, you see a lot of  
> the same structures (like "an area containing a label and an  
> attribute editor") and constants (like the borders around various  
> blocks).
>
>
>
>

I was under the impression that one would be free to mix python  
declarations & cpia xml.  Using python for something complex like the  
detail view would be quite useful, but for a hierarchy of a dozen  
menus & menu items cpia xml could be useful.

I'm also imagining CPIA XML to use for little fragments you load in  
installParcel() python then swap around places -- for example, define  
a dialog UI in one little cpia xml file, then save the block tree to  
an array of dialog blocktrees somewhere, or something like that.

So I know that everyone here dislikes or hates parcel.xml, but it did  
manage to do one thing: abstract away the parcel loading process into  
a declarative system.  It was successful enough that I, a chandler  
semi-newcomer, didn't really understand anything about the parcel  
loading system for months even though I was hip deep in CPIA  
refactoring the calendar UI into CPIA blocks.  Everything I wrote was  
either declarative parcel.xml, or else methods on the python Kind  
classes.

I guess you all understood parcel.xml was an abstraction, and had  
more experience where the abstraction broke down, but I was thinking  
in terms of it enough that the lower-level procedural approach  
installParcel() was a bit counterintuitive for a while.

There's TWO types of python code: (1) installParcel() loading code,  
and (2) declaration of Kind classes.  You're always going to have to  
do (2), but either CPIA XML or a GUI builder could replace (1).  (For  
the CPIA XML you'd need 3 lines of boilerplate installParcel() of  
course.)  In either a GUI builder or CPIA XML world, a new developer  
could get away with only writing python class/Kind declarations, and  
then if they wanted to do something advanced (like the detail view)  
they could learn installParcel() -- which makes sense because it's  
lower-level & procedural.

that story is basically how I learned things over the past few  
months, though it would have been much nicer with cpia xml instead of  
parcel.xml.  None of my UI work involved complex manipulations or  
patterns of blocks, so if installParcel() had never come out, I still  
would've been happily thinking in declarative terms today.

Brendan






>
> The thing I hate most about parcel.xml is that there's no way for  
> me to represent or encapsulate this repetiton; the new proposal  
> suffers from the same problem. Declaring things in Python will let  
> me parameterize generation of these elements. (Getting names of  
> blocks right is trivial, but getting things to align consistently,  
> given native-control weirdness across platforms, has consumed  
> inordinately-huge amounts of my time.)
>
> ...Bryan
>
> Alec Flett wrote:
>
>
>
>
>> I feel like folks are leaning towards pje's python .update  
>> mechanism as the GUT of item declaration.. and I think that's a  
>> mistake and I think its because people feel burned by parcel.xml.  
>> Its the underlying API sure, but if we never HAD parcel.xml, I can  
>> guarantee you that I wouldn't be the first one to say ".update()  
>> is really tedious for the UI - lets find a simpler way to declare  
>> this stuff.. what about xml?"
>>
>>
>>
>>
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
>
>
>