What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

In WPF, if I want to make some sort of custom control (which I do a lot, for
modularity's sake, even if the control is only used in one place), I most
often subclass UserControl, which is a boring class that has a single
Content element.  What's the corresponding thing in Pivot?

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> What I'd like to understand is why BoxPane (or TablePane) is "terrible" for
> this particular case. If you were focusing purely on layout (never mind the
> code behind), what container would you use? TablePane is pretty flexible,
> and very similar to an HTML table, which is also popular for laying out
> complex forms. Why not use it?
>

TablePane is a fine container, and I expect to use it for most interesting
layouts.  I was merely declining to extend it to make my backing class, for
simplicity of understanding the bxml.  That may just be my WPF bias, and
your explanation of why it wouldn't be weird is reasonable.  I might rethink
that at some point.

BoxPane is fine for simple things.  I just know now not to nest other
containers (except maybe another BoxPane) in it.  The analogous WPF control
(StackPanel) has similar issues.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> You could do something similar in BXML by using a BoxPane with orientation="vertical" as the root element. However, since BXML isn't compiled, this file won't be tied to any code. So, you need to create a class that extends BoxPane and use that as your root element: <my:MyBoxPane>. This class will generally implement Bindable, which provides the initialize() method that you can use to perform your initialization, similar to XAML and MXML.
> 
> Which is exactly what I'm doing, except that I've elected to use StackPane rather than BoxPane, which is a terrible choice for the reasons I mentioned earlier (not layout-transparent -- even if I put orientation="vertical" styles="{fill:true}" on my root element, which is a nuisance, it still doesn't do what I want.  Apparently fill only applies to the orthogonal dimension of the BoxPane's orientation).

This is why I keep driving the question about use case. BoxPane isn't a "terrible" component. There are plenty of use cases where BoxPane would be a valid base class - in fact, as I mentioned, when I was doing Flex development I often used a VBox as a base class for MXML components. Same goes for TablePane.

What I'd like to understand is why BoxPane (or TablePane) is "terrible" for this particular case. If you were focusing purely on layout (never mind the code behind), what container would you use? TablePane is pretty flexible, and very similar to an HTML table, which is also popular for laying out complex forms. Why not use it?

I understand that it seems odd to you to have row and column markup associated with an element that isn't obviously a TablePane, but in practice, it works pretty well. In fact, it is no different from any other subclass - you generally can't tell until you look at the Javadoc what a given class's base class is. Once you know that TabSettingsGeneralPanel extends TablePane, you know that you can either use the row and column markup on it, or you can call getRows() and getColumns() directly. So I don't think it is all that weird.

G

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> You could do something similar in BXML by using a BoxPane with
> orientation="vertical" as the root element. However, since BXML isn't
> compiled, this file won't be tied to any code. So, you need to create a
> class that extends BoxPane and use that as your root element:
> <my:MyBoxPane>. This class will generally implement Bindable, which provides
> the initialize() method that you can use to perform your initialization,
> similar to XAML and MXML.
>

Which is exactly what I'm doing, except that I've elected to use StackPane
rather than BoxPane, which is a terrible choice for the reasons I mentioned
earlier (not layout-transparent -- even if I put orientation="vertical"
styles="{fill:true}" on my root element, which is a nuisance, it still
doesn't do what I want.  Apparently fill only applies to
the orthogonal dimension of the BoxPane's orientation).

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

I'll admit that, though I'm familiar with WPF, I'm not an expert and have never developed an application with it. I have used Flex however, which also compiles markup to classes. So, in Flex, I might create a file named TabSettingsGeneral.mxml. The root element of this file might be a <VBox>. This means that VBox will be the base class for the generated class, whose name will be TabSettingsGeneral. The MXML compiler will insert code to call the initialize() method on the generated class, so you can wire up event listeners, etc. I imagine that this is similar to InitializeComponent() in XAML.

You could do something similar in BXML by using a BoxPane with orientation="vertical" as the root element. However, since BXML isn't compiled, this file won't be tied to any code. So, you need to create a class that extends BoxPane and use that as your root element: <my:MyBoxPane>. This class will generally implement Bindable, which provides the initialize() method that you can use to perform your initialization, similar to XAML and MXML.

Does this help?


On Dec 3, 2010, at 9:34 PM, Greg Brown wrote:

>> If you create a class Foo that extends Component, you can use it in BXML just like any other component
>> 
>> True, if Foo is defined solely in Java.
> 
> What I meant is that it doesn't have to be a subclass of Container (though it often probably will be). I was just trying to convey that you don't *need* to create an intermediary element if your use case doesn't call for it.
> 
>> But that's not what I'm talking about.  I want to create components using bxml with Java behind them.  Which, if one reads the various tutorials and your replies to other messages, seems to be what you think, too.
> 
> Yes.  :-)
> 
>> And you can only use that kind of component in someone else's BXML via the include construct.  It would be cool if that weren't so.  Suppose there were another entry into the bxmlserializer that I could call from my constructor to say "make my content be the stuff you find in the following bxml file" (which at least conceptually is what happens in the InitializeComponent call in every xaml-based class in WPF).  
> 
> Sort of. A XAML file gets compiled to a class instance, and InitializeComponent() is likely called by some glue code generated by the compiler. It's not exactly the same as deserializing BXML in a constructor. In BXML, the root element is instantiated by BXMLSerializer, not the new operator.
> 
>> I'm puzzled that you're not following me.  I must really be thinking of UI construction very differently than you.  So I'll take a stab at the concrete example you ask for.
>> 
>> Here's an example of the "making it manageable" situation that comes up periodically for me.  An app has a settings dialog, with a bunch of tabs devoted to different categories of settings.  You could create a monster bxml file whose main portion looks like this:
>> 
>> <TabPane ...>
>>   <TablePane bxml:id="tabGeneral" TabPane.tabData="General">
>>         ... lots of stuff ...
>>   </TablePane>
>>   <Form bxml:id="tabContact" TabPane.tabData="Contact Info">
>>         ... other stuff  ...
>>   </Form>
>>   <Panel bxml:id="tabCreative" TabPane.tabData="Go Wild">
>>         ... silly stuff ...
>>   </Panel>
>>   ... more tabs ...
>> </TabPane>
>> 
>> and have a huge pile of code in the settings dialog class to initialize the fields and later process them when the user clicks OK.
>> 
>> But to make it manageable, especially if different people are responsible for each category, I'd much rather have the main dialog look like
>> 
>> <TabPane ...>
>>   <my:TabSettingsGeneral />
>>   <my:TabSettingsContact  />
>>   <my:TabSettingsCreative />
>>   ...
>> </TabPane>
>> 
>> Then I'd take that big blob of bxml from the first tab and put it into TabSettingsGeneral.bxml, and put the code responsible for initializing it and processing it into TabSettingsGeneral.java.  And similarly for the other tabs.
>> 
>> Of course, I can't quite do it that way, for the reasons described in my first paragraph, so in the current Pivot I settle for 
>> 
>> <TabPane ...>
>>   <bxml:include src="TabSettingsGeneral.bxml" />
>>   <bxml:include src="TabSettingsContact.bxml" />
>>   <bxml:include src="TabSettingsCreative.bxml" />
>>   ...
>> </TabPane>
>> 
>> And, of course TabSettingsGeneral.bxml has to be wrapped in my new Java class so that it will create the class:
>> 
>> <my:TabSettingsGeneral ...>
>>    ... the actual blob from above ...
>> </my:TabSettingsGeneral>
>>   
>> Am I being any clearer yet?
> 
> Yes, but I'm still not sure what the actual problem is. I think your question is, what class should you use as the base class for TabSettingsGeneral. Is that correct? If so, the answer is whatever layout container is most appropriate for that part of your UI. TablePane is pretty common for TabPane content, but of course you can use any Component.
> 
>> By the way, in the reorganization I described above I left out the setting of TabPane.tabData for each component.  I can't put it in TabSettingsGeneral.bxml, because the serializer apparently doesn't know it's inside a TabPane at that point.  So I was pleased but rather surprised to find that the following works:
>> 
>> <bxml:include src="TabSettingsGeneral.bxml" TabPane.tabData="General"/>
>> 
>> What else can you put in an include element?
> 
> You can basically use any property of the class corresponding to the root element of the include. For example, if your include contained a Label, you could do this:
> 
> <bxml:include src="my_label.bxml" text="Hello World"/>
> 
> A <bxml:include> is essentially the equivalent of the new operator. You are instantiating an object based on the template defined in the BXML file.
> 

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> I think your question is, what class should you use as the base class for
> TabSettingsGeneral. Is that correct? If so, the answer is whatever layout
> container is most appropriate for that part of your UI. TablePane is pretty
> common for TabPane content, but of course you can use any Component.
>

Yes.  But as I said, I don't like the fact that this way of doing things
makes the bxml weirder.  I have to know that my root class is a TablePane to
make sense of the fact that my markup starts with a <columns> element and
then has TablePane.Row elements.  Well, I suppose that case might be kind of
obvious :-).  Or if my root class extends GridPane, I have to know that to
understand why there's this weird columnCount attribute on the root element.
 Or in general what the styles on the root element are referring to.

Okay, maybe it wouldn't be a big hurdle in practice.  I think I'll stay with
the extra level of hierarchy for now for simplicity.  Surely there can't be
a huge performance penalty.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> Which is why I said conceptually, though maybe that's not the best word.  From the programmer's naive point of view (i.e., what you might think if you don't look inside the .g file), someone calls new Foo(), at which point the constructor calls InitializeComponent, whose mission is to "go do all that stuff the xaml file says".
>  
> It's not exactly the same as deserializing BXML in a constructor. In BXML, the root element is instantiated by BXMLSerializer, not the new operator.
> 
> Yes.  But does it have to be that way?  I haven't looked at the BXMLSerializer code, so perhaps I'm being naive, but it seems like you could have a different entry point to the code, one that accepts the already-created root class as a parameter rather than creating one only after parsing the root element.

This is theoretically possible. An argument could be added to BXMLSerializer#readObject(InputStream) that contains the root object to use, rather than assuming that it is null. The constructor could then call:

  readObject(getClass().getResourceAsStream("Foo.bxml"), this);

and ignore the return value (since it would be the same as this, and constructors can't return anything anyway). Not a bad idea. Definitely something to think about for a future release.

G

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> What I meant is that it doesn't have to be a subclass of Container (though
> it often probably will be).
>

Pretty much has to be for any but the most trivial component, but I
understand in principle.

Sort of. A XAML file gets compiled to a class instance, and
> InitializeComponent() is likely called by some glue code generated by the
> compiler.
>

Which is why I said conceptually, though maybe that's not the best word.
 From the programmer's naive point of view (i.e., what you might think if
you don't look inside the .g file), someone calls new Foo(), at which point
the constructor calls InitializeComponent, whose mission is to "go do all
that stuff the xaml file says".


> It's not exactly the same as deserializing BXML in a constructor. In BXML,
> the root element is instantiated by BXMLSerializer, not the new operator.
>

Yes.  But does it have to be that way?  I haven't looked at
the BXMLSerializer code, so perhaps I'm being naive, but it seems like you
could have a different entry point to the code, one that accepts the
already-created root class as a parameter rather than creating one only
after parsing the root element.  In such a world, the class constructor
could call BXMLSerializer.InitializeComponent(this, "whatever.bxml"). Then
anyone could new the component without needing to know there was a bxml
file, and in someone else's bxml file you could treat the custom component
on equal footing with any built-in Pivot component, including setting its
properties:

   <my:Foo blinkRate="5" showDetails="true" />

Well, I see from your last remark I can set properties from the include
element already, so this last point isn't a big breakthrough.  But I think
the not needing to know that some component classes are defined with a bxml
file and some aren't would be a win.  Just a thought.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> If you create a class Foo that extends Component, you can use it in BXML just like any other component
> 
> True, if Foo is defined solely in Java.

What I meant is that it doesn't have to be a subclass of Container (though it often probably will be). I was just trying to convey that you don't *need* to create an intermediary element if your use case doesn't call for it.

> But that's not what I'm talking about.  I want to create components using bxml with Java behind them.  Which, if one reads the various tutorials and your replies to other messages, seems to be what you think, too.

Yes.  :-)

> And you can only use that kind of component in someone else's BXML via the include construct.  It would be cool if that weren't so.  Suppose there were another entry into the bxmlserializer that I could call from my constructor to say "make my content be the stuff you find in the following bxml file" (which at least conceptually is what happens in the InitializeComponent call in every xaml-based class in WPF).  

Sort of. A XAML file gets compiled to a class instance, and InitializeComponent() is likely called by some glue code generated by the compiler. It's not exactly the same as deserializing BXML in a constructor. In BXML, the root element is instantiated by BXMLSerializer, not the new operator.

> I'm puzzled that you're not following me.  I must really be thinking of UI construction very differently than you.  So I'll take a stab at the concrete example you ask for.
> 
> Here's an example of the "making it manageable" situation that comes up periodically for me.  An app has a settings dialog, with a bunch of tabs devoted to different categories of settings.  You could create a monster bxml file whose main portion looks like this:
> 
> <TabPane ...>
>   <TablePane bxml:id="tabGeneral" TabPane.tabData="General">
>         ... lots of stuff ...
>   </TablePane>
>   <Form bxml:id="tabContact" TabPane.tabData="Contact Info">
>         ... other stuff  ...
>   </Form>
>   <Panel bxml:id="tabCreative" TabPane.tabData="Go Wild">
>         ... silly stuff ...
>   </Panel>
>   ... more tabs ...
> </TabPane>
> 
> and have a huge pile of code in the settings dialog class to initialize the fields and later process them when the user clicks OK.
> 
> But to make it manageable, especially if different people are responsible for each category, I'd much rather have the main dialog look like
> 
> <TabPane ...>
>   <my:TabSettingsGeneral />
>   <my:TabSettingsContact  />
>   <my:TabSettingsCreative />
>   ...
> </TabPane>
> 
> Then I'd take that big blob of bxml from the first tab and put it into TabSettingsGeneral.bxml, and put the code responsible for initializing it and processing it into TabSettingsGeneral.java.  And similarly for the other tabs.
> 
> Of course, I can't quite do it that way, for the reasons described in my first paragraph, so in the current Pivot I settle for 
> 
> <TabPane ...>
>   <bxml:include src="TabSettingsGeneral.bxml" />
>   <bxml:include src="TabSettingsContact.bxml" />
>   <bxml:include src="TabSettingsCreative.bxml" />
>   ...
> </TabPane>
> 
> And, of course TabSettingsGeneral.bxml has to be wrapped in my new Java class so that it will create the class:
> 
> <my:TabSettingsGeneral ...>
>    ... the actual blob from above ...
> </my:TabSettingsGeneral>
>   
> Am I being any clearer yet?

Yes, but I'm still not sure what the actual problem is. I think your question is, what class should you use as the base class for TabSettingsGeneral. Is that correct? If so, the answer is whatever layout container is most appropriate for that part of your UI. TablePane is pretty common for TabPane content, but of course you can use any Component.

> By the way, in the reorganization I described above I left out the setting of TabPane.tabData for each component.  I can't put it in TabSettingsGeneral.bxml, because the serializer apparently doesn't know it's inside a TabPane at that point.  So I was pleased but rather surprised to find that the following works:
> 
> <bxml:include src="TabSettingsGeneral.bxml" TabPane.tabData="General"/>
> 
> What else can you put in an include element?

You can basically use any property of the class corresponding to the root element of the include. For example, if your include contained a Label, you could do this:

<bxml:include src="my_label.bxml" text="Hello World"/>

A <bxml:include> is essentially the equivalent of the new operator. You are instantiating an object based on the template defined in the BXML file.

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> If you create a class Foo that extends Component, you can use it in BXML
> just like any other component
>

True, if Foo is defined solely in Java. But that's not what I'm talking
about.  I want to create components using bxml with Java behind them.
 Which, if one reads the various tutorials and your replies to other
messages, seems to be what you think, too.  And you can only use that kind
of component in someone else's BXML via the include construct.  It would be
cool if that weren't so.  Suppose there were another entry into the
bxmlserializer that I could call from my constructor to say "make my content
be the stuff you find in the following bxml file" (which at least
conceptually is what happens in the InitializeComponent call in every
xaml-based class in WPF).  Then I could even do new Foo() from other Java
code that's constructing some UI on the fly.

I'm puzzled that you're not following me.  I must really be thinking of UI
construction very differently than you.  So I'll take a stab at the concrete
example you ask for.

Here's an example of the "making it manageable" situation that comes up
periodically for me.  An app has a settings dialog, with a bunch of tabs
devoted to different categories of settings.  You could create a monster
bxml file whose main portion looks like this:

<TabPane ...>
  <TablePane bxml:id="tabGeneral" TabPane.tabData="General">
        ... lots of stuff ...
  </TablePane>
  <Form bxml:id="tabContact" TabPane.tabData="Contact Info">
        ... other stuff  ...
  </Form>
  <Panel bxml:id="tabCreative" TabPane.tabData="Go Wild">
        ... silly stuff ...
  </Panel>
  ... more tabs ...
</TabPane>

and have a huge pile of code in the settings dialog class to initialize the
fields and later process them when the user clicks OK.

But to make it manageable, especially if different people are responsible
for each category, I'd much rather have the main dialog look like

<TabPane ...>
  <my:TabSettingsGeneral />
  <my:TabSettingsContact  />
  <my:TabSettingsCreative />
  ...
</TabPane>

Then I'd take that big blob of bxml from the first tab and put it
into TabSettingsGeneral.bxml, and put the code responsible for initializing
it and processing it into TabSettingsGeneral.java.  And similarly for the
other tabs.

Of course, I can't quite do it that way, for the reasons described in my
first paragraph, so in the current Pivot I settle for

<TabPane ...>
  <bxml:include src="TabSettingsGeneral.bxml" />
  <bxml:include src="TabSettingsContact.bxml" />
  <bxml:include src="TabSettingsCreative.bxml" />
  ...
</TabPane>

And, of course TabSettingsGeneral.bxml has to be wrapped in my new Java
class so that it will create the class:

<my:TabSettingsGeneral ...>
   ... the actual blob from above ...
</my:TabSettingsGeneral>

Am I being any clearer yet?

By the way, in the reorganization I described above I left out the setting
of TabPane.tabData for each component.  I can't put it
in TabSettingsGeneral.bxml, because the serializer apparently doesn't know
it's inside a TabPane at that point.  So I was pleased but rather surprised
to find that the following works:

<bxml:include src="TabSettingsGeneral.bxml" TabPane.tabData="General"/>

What else can you put in an include element?

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

I'm sorry, I don't completely understand that reasoning. If you create a class Foo that extends Component, you can use it in BXML just like any other component:

<my:Foo>
...
</my:Foo>

You don't need some intermediate parent:

<my:Bar>
  <content>
    <my:Foo>
    ...
    </my:Foo>
  </content>
</my:Bar>

(though the <content> tag could be optional if it was defined as the default property)

But without a concrete example, I'm really not sure what to suggest.

G

On Dec 2, 2010, at 10:44 PM, Bill van Melle wrote:

> Why not simply use the child element as the root? 
> 
> Because I want a class backing the bxml to provide behavior and whatnot.

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> Why not simply use the child element as the root?
>

Because I want a class backing the bxml to provide behavior and whatnot.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> I want a methodology for creating custom Component subclasses using BXML markup.  I want to be able to place such a component into other components, sometimes by markup (bxml:include), sometimes programmatically (by deserializing the bxml, which as I described earlier, I hide by a static factory method on my component's class).

This makes sense.

> Seems like I need to subclass a container, since otherwise how does the bxml serializer interpret the child of the root element?  

Why not simply use the child element as the root? Is there any reason to add another level to the hierarchy?

> Panel is certainly not what I want. I do want my component to undergo layout.

So again, it really depends on what kind of layout you want to use. The layout containers provided by the platform cover a pretty large number of use cases. If you find that they aren't sufficient for your needs, it really isn't tough to create your own container. It also isn't that difficult to create a completely custom component. A concrete example would probably help here.

G

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

>
> I'm really not sure what you are trying to accomplish,
>

The short answer is I'm trying to mimic WPF's UserControl.

Longer answer.  I want a methodology for creating custom Component
subclasses using BXML markup.  I want to be able to place such a component
into other components, sometimes by markup (bxml:include), sometimes
programmatically (by deserializing the bxml, which as I described earlier, I
hide by a static factory method on my component's class).

Seems like I need to subclass a container, since otherwise how does the bxml
serializer interpret the child of the root element?  While I will normally
make that child itself be some kind of container, I think it's more
straightforward and easier to understand the bxml if the particular
container I've selected for my layout needs is right there in the bxml,
rather than somehow implicit in the root element's class and varying from
one bxml file to another.  Yes, it's an extra layer of indirection, but I
think it's conceptually simpler.

Panel is certainly not what I want. I do want my component to undergo
layout. Panel children have to specify x, y, and size.  Not remotely what
I'm interested in.

There's a separate question for later on about what kind of support exists
for defining your own custom containers, but this is not it.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> Well, BoxPane seems a poor choice, given that it doesn't propagate size information, leading to the multiple confusions I've been a victim to already.

Not sure what you mean by "propagate size information". But it depends on what you need the container to do. If you expect your custom component to lay out its content in a horizontal or vertical row, then BoxPane would be a good choice.

> TablePane is an even worse choice.  Unlike the corresponding WPF container (Grid), TablePane requires row and column markup, even if it only contains a single child.

Again, it depends on what your needs are. If you need to lay out content in rows and columns, then TablePane would certainly be a good choice.

> I'm thinking StackPane might be the best choice.  It seems to be pretty transparent.

I'm really not sure what you are trying to accomplish, but if you want something that can simply act as a container for other components, you might want to look at Panel. It is the simplest container possible as it doesn't perform any layout.

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

Well, BoxPane seems a poor choice, given that it doesn't propagate size
information, leading to the multiple confusions I've been a victim to
already.

TablePane is an even worse choice.  Unlike the corresponding WPF container
(Grid), TablePane requires row and column markup, even if it only contains a
single child.

I'm thinking StackPane might be the best choice.  It seems to be pretty
transparent.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

That is true, but it shouldn't have anything to do with subclassing. That just means that you can't add a Window to another container (except a Display).

Most of the tutorial examples use this approach - for example:

http://svn.apache.org/repos/asf/pivot/trunk/tutorials/src/org/apache/pivot/tutorials/buttons/PushButtons.java
http://svn.apache.org/repos/asf/pivot/trunk/tutorials/src/org/apache/pivot/tutorials/buttons/push_buttons.bxml

If you want to create a component that you can use within another container, you'll need to extend a different class. Maybe BoxPane or TablePane?

On Dec 2, 2010, at 1:12 AM, Bill van Melle wrote:

> Well, Window was the first thing I tried subclassing, but it doesn't work -- it complained that it couldn't parent a Window to anything but a display.

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

Well, Window was the first thing I tried subclassing, but it doesn't work --
it complained that it couldn't parent a Window to anything but a display.

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

> Well, no, I generally don't want to go creating skins.  Sure, if I was building a component to add to a library, that would make sense, but I'm thinking more often of just ways of splitting a window into manageable pieces.  You have the bxml:include construct to help with that, but I don't want to just include markup, I want to also include the "backing class" for that markup.
> 
> E.g., in WPF, I might create a component Foo to handle the interaction in one tab of what you call a TabPane.  So the contents of the tab would be just
> 
>    <my:Foo Name="myFoo" />
> 
> In Pivot, since backing classes aren't tied explicitly to bxml, I believe I'd have to say the wordier
> 
>    <bxml:include bxml:id="myFoo" src="Foo.bxml" />

That's correct - this is because BXML isn't compiled, whereas XAML is.

> and the root element of Foo.bxml would be my:Foo.  So my question amounted to, what should Foo ideally extend so as to carry the least baggage?

It really depends on your app. I often end up subclassing Window or one of its subclasses, since these generally represent reusable chunks of functionality.

G

Re: What's the best component to subclass?

[Bill van Melle <bi...@gmail.com>]

Well, no, I generally don't want to go creating skins.  Sure, if I was
building a component to add to a library, that would make sense, but I'm
thinking more often of just ways of splitting a window into manageable
pieces.  You have the bxml:include construct to help with that, but I don't
want to just include markup, I want to also include the "backing class" for
that markup.

E.g., in WPF, I might create a component Foo to handle the interaction in
one tab of what you call a TabPane.  So the contents of the tab would be
just

   <my:Foo Name="myFoo" />

In Pivot, since backing classes aren't tied explicitly to bxml, I believe
I'd have to say the wordier

   <bxml:include bxml:id="myFoo" src="Foo.bxml" />

and the root element of Foo.bxml would be my:Foo.  So my question amounted
to, what should Foo ideally extend so as to carry the least baggage?

Re: What's the best component to subclass?

[Greg Brown <gk...@verizon.net>]

If you want to create a completely new component, you should subclass Component and create a corresponding skin (which will generally extend org.apache.pivot.wtk.skin.ComponentSkin, but can simply implement org.apache.pivot.wtk.Skin if you prefer).

If your class bears any similarity to an existing component, you would almost certainly be better off subclassing that. In this case, you'll probably also want to create a custom skin subclass that extends the default skin for that component. However, if you do want to create an entirely new component, you can look at the Ruler component in the ScrollPane tutorial for an example:

http://svn.apache.org/repos/asf/pivot/trunk/tutorials/src/org/apache/pivot/tutorials/navigation/

See Ruler.java, RulerListener.java, and RulerSkin.java.

G

On Dec 1, 2010, at 8:04 PM, Bill van Melle wrote:

> In WPF, if I want to make some sort of custom control (which I do a lot, for modularity's sake, even if the control is only used in one place), I most often subclass UserControl, which is a boring class that has a single Content element.  What's the corresponding thing in Pivot?
>