Re: JPanel used for graphics

Hi Frank, 

Thanks for the comments.  Here are some responses. 

> First, there is no way to have a component inside a
> container twice. So, what to do if you use the id
> "xc_panel" twice?

Reusing a component variable is a problem in the current
scheme and isn't relevant to my proposal. 

> Second, the changes you suggest
> are (as far as I remember the places correctly) in
> swixml much greater than the code you need to add
> this new tag:

Yes, but I'm not proposing changing Swixml just to
solve my problem.  It was mentioned on this mailing
list as a possible solution that might solve other
users problems.  If it doesn't, then it probably isn't
worth putting in to Swixml. 

> Swixml:
> - check if the variable specified by "id" does exist
> - check if it has the right type (what if not?)
> - check if the variable is alreay in some container
>   (this may not be necessary, or may lay in the
>   responsibility of the callers class)
> Allthough reflection gained a lot of speed, this
> would be quite time consuming, I suppose.

Swixml must already check for existence, and the
responsibility for where it's used is not Swixml's.
It's hard to believe much time would be used, and
perhaps no more than the consequences of registering
another tag. 

<offtopic>
 This constant worry about execution time is interesting.
 The most obvious improvement would seem to come from
 transforming the xml into executable Java code, or at
 least having that as an option.  I find it hard to
 believe that many GUIs depend on anything at run time.
 Surely there are cases, but for the majority of us it
 would be fine to just compile the generated interface code.
</offtopic> 


> In your code, you write simple
> swix.getTaglib().registerTag( "diagram", Diagram.class );

If it is this simple, it's the most compelling argument against
my proposal.  However, there seems to be something that I'm missing
because I get the following.  Maybe the id= or contraints= attributes?
    [java] SwixML 1.1 (#139)
    [java] java.lang.IllegalAccessException:
           Class org.swixml.DefaultFactory can not access a member
           of class com.fredswartz.skeema.Diagram with modifiers ""
    [java]     at sun.reflect.Reflection.ensureMemberAccess
          (Reflection.java:57)
    . . .
Unfortunately, I'm out of time for this project until the end of the
week.  I'll play around with it some more then. 

> Third, this leads to unflexible xml-files. If you have
> a varity diagrams to choose from (preferable sharing
> an appropriate interface) you just register these
> classes. Then you choose whatever diagram is best
> in your xml-file. With your approach, this would'nt
> work easily.

Not a problem at all.  I would simply initialize the variable
with whichever class was appropriate.  But this isn't a factor
in my program. 

Thanks for the comments, 

 -- Fred 


> 
> Yours, 
> 
> Frank 
> 
> 
> List for Users of Carlsbad Cubes' Technologies and Products schrieb am 27.03.04 23:54:54:
>> 
>> Frank,  
>> 
>> Here's a clarification.  
>> 
>> I had proposed a simple way to use subclassed components by allowing the 
>> user to intitialize them.  My original text was  
>> 
>> > The Swix engine could check 
>> > to see if a variable to which a tag is bound already has a non-null value.  
>> > If it's null, then it should create a new instance as it does now.  If it's 
>> > non-null and it's an instance of the appropriate type, then the xml 
>> > attributes should be applied to the existing value.  I'm not sure whether 
>> > it's an easy solution to any other problems, but it would be a simple 
>> > solution to my subclassing problem. 
>> 
>> Here are some snippets of code to illustrate what I mean more concretely.  
>> 
> 
>> === From XML file =======================
>> <!-- I want a panel (xc_panel) in the frame, but really want it to be a
>>     Diagram (subclass of JPanel).  See below. -->
>> . . .
>> <panel id="xc_panel" preferredSize="500,500" 
>> constraints="BorderLayout.CENTER">
>> </panel>
>> . . .  
>> 
>> === From Diagram.java =============================
>> // This is the subclass of JPanel that I want xc_panel to be.
>> public class Diagram extends JPanel {
>> . . .
>>    public paintComponent(Graphics g) {
>>       // Draw my diagram to repaint the panel.
>>       . . .
>>    }
>> }  
>> 
>> === From my main class ===========================
>> // A possible solution is the following.  Note that THIS DOES NOT WORK
>> // because Swixml always creates a new JPanel from the xml file
>> // and overwrites my assignment to xc_panel.
>> public class MyController {
>>    . . .
>>    public Diagram xc_panel;   // This is initialized by swixml
>>    . . .
>>    public MyController() {
>>        xc_panel = new Diagram();   // I WOULD LIKE THIS TO WORK.
>>        SwingEngine swix = new SwingEngine( this );
>>        swix.render( "XXX.xml" );
>>        . . . // render() has assigned a new panel to xc_panel :-(
>>    }
>> . . .  
>> 
>> The Diagram/JPanel variable xc_panel is specified in the .xml and
>> initialized by the swix.render call.  What I'd prefer the SwingEngine
>> to do it take a look at the contents of xc_panel before it creates
>> a new JPanel.  If xc_panel already contains a JPanel, as my example
>> does, it should not create a new one, but use the existing one and
>> simply apply any specifed attributes to it -- in my case a preferred
>> size of 500x500 was specified.  
>> 
>> This appears to be a simple solution to my problem where I must subclass
>> JPanel to override paintComponent().  I believe allowing user initialization
>> of components might also provide a solution to problems that initclass can't
>> easily solve.  
>> 
>>  -- Fred  
>> 
>>   
>> 
>>   
>> 
>>   
>> 
>> [email protected] writes:  
>> 
>> > List for Users of Carlsbad Cubes' Technologies and Products schrieb am 27.03.04 18:16:58:
>> >> 
>> >> It appears that the way to do this is to register a new tag for this 
>> >> subclass of JPanel that I've defined.  Is this the correct approach? 
>> > 
>> > At least this seems the most reasonable thing to me.
>> > Easy, documented and IMHO well used. 
>> > 
>> >> 
>> >> This got me to thinking about other approaches.  The Swix engine could check 
>> >> to see if a variable to which a tag is bound already has a non-null value.  
>> >> If it's null, then it should create a new instance as it does now.  If it's 
>> >> non-null and it's an instance of the appropriate type, then the xml 
>> >> attributes should be applied to the existing value.  I'm not sure whether 
>> >> it's an easy solution to any other problems, but it would be a simple 
>> >> solution to my subclassing problem. 
>> > 
>> > Could you please explain this with some (pseudo) code? I do not
>> > grab it... 
>> > 
>> > Frank 
>> > 
>> >  
>> > 
>> > 
>> > _______________________________________________
>> > Forum mailing list
>> > [email protected]
>> > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>   
>> 
>> 
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>  
> 
>  
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com