Re: component definitions

Hey, I'm chiming in late here, but this discussion seems like we're  
smacking our heads against a brick wall a little bit. I think this  
whole confusion is kind of related to the problem that lots of  
developers have understanding the difference between "Class" and  
"Instance".  Christian wants to put an *instance* of a component on  
lots of pages, and doesn't seem to get that he needs to (to borrow the  
OO term) *instantiate* it.   In Java, you need to instantiate objects  
that you want to use, or you create static methods that do it for you.   
If you want a singleton for example, you still need to instantiate it  
once, and you need to do that work yourself.   This is no different to  
how you set up your pages in Tapestry (or WebObjects, of course),  
except it's not classes we're talking about, it's components.

If you want an instance of your calendar object on a whole slew of  
different pages, create a component that needs no parameters and  
displays your component with all of its parameters set the way you like  
them, and then put *that* component on all your pages.   You get your  
calendar all nicely configured and it doesn't take a bunch of lines in  
your .jwc files, as described by MindBridge below.

Or is that still too hard?

Kyle Dawkins
Central Park Software

On Thursday, Dec 19, 2002, at 12:27 US/Eastern, Mind Bridge wrote:

> Hi Christian,
>
> I think am clear as to what you suggest (see below for an example).  
> Here is
> an example of what I am talking about:
>
>>> New Component (Tapestry 2.4):
>>> -----------------------------
>>> 1 x defining a new component
>>> 	5 lines + 'component configuration', 1 line template, 1 line alias
>>>
>>> N x using the new component
>>> 	1 line in template
>
>> huh? Sorry I really cannot follow. What are those 5 lines?
>
> JWC:
> ----
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE component-specification PUBLIC "-//Howard Lewis  
> Ship//Tapestry
> Specification 1.3//EN"
>       "http://tapestry.sf.net/dtd/Tapestry_1_3.dtd">
> <component-specification class="net.sf.tapestry.BaseComponent">
>
> 	<!-- begin component configuration -->
> 	<component id="compId" type="SomeComponentThatNeedsToBeConfigured">
> 		<binding name="someParameter1" expression="some value 1"/>
> 		<binding name="someParameter2" expression="some value 2"/>
> 	</component>
> 	<!-- end component configuration -->
>
> </component-specification>
>
> Template:
> ---------
> <span jwcid="compId"/>
>
> App spec:
> ---------
> <component-alias type="ConfiguredComponent" specification-path="..."/>
>
> Using the new component in every relevant page (same effect as what you
> suggest):
> ----------------------------------------------------------------------- 
> -
> <span jwcid="@ConfiguredComponent"/>
>
>
>
>> What is "? lines + 'component configuration'"?
>
> What you suggest is to put the following block in the App spec instead:
>
> 	<!-- begin component configuration -->
> 	<component id="compId" type="SomeComponentThatNeedsToBeConfigured">
> 		<binding name="someParameter1" expression="some value 1"/>
> 		<binding name="someParameter2" expression="some value 2"/>
> 	</component>
> 	<!-- end component configuration -->
>
> and make it possible for that component to be used in all application  
> pages
> and components in the following way:
>
> <span jwcid="compId"/>
>
>
> As you can see, the difference between the above approaches is  
> precisely 7
> lines in the locations that I have specified. I have put the '? lines'
> because it is possible that additional code may be needed, although it  
> is
> not apparent that it is at this point.
>
> Note that there is basically no difference between the two approaches  
> when
> 'use' is concerned -- they both require one short line.
>
>
> I have to go out in about -5 minutes, so just a few quick final  
> remarks for
> now:
>
>> 1. make type aliases optional (tapestry 2.4?)
>
> This is where we come from, actually. In the pre-2.2 world aliases were
> optional and Spindle, for example, did not use them at all. This is  
> not very
> compatible with the notion of libraries, however. Please have a look  
> at the
> mailing list archives on this topic, or perhaps Howard can explain his  
> point
> of view.
>
>
> I hope this makes things clearer.
>
> You proposal is definitely interesting, but I think the 'composing
> component' one described above is very close.
>
> Best regards,
> -mb
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Geek Gift Procrastinating?
> Get the perfect geek gift now!  Before the Holidays pass you by.
> T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
> _______________________________________________
> Tapestry-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>



-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/