Re: XUL Tag Plugins

Blake Williams <[email protected]>
Newsgroups gmane.comp.java.luxor-xul.user
Message-ID <[email protected]>
I'm not sure XBL is a valid solution for luxor because I don't know the  
luxor code well enough to know if it fits the overall architecture. XBL  
is like its own xul document, including scripts, with a single api to a  
parent xul document. All components's api's in the xbl document are  
represented as a single api. XBL components manifest themselves in the  
parent document as a tag <MyComponent/>, but it can pass through child  
components as well <MyComponent><image/><MyComponent>. I think there  
are 2 aspects to xbl that may be useful in luxor:

1) it is a way to add new component dynamically i.e. post compiling
2) It defines how to handle children

For example, if the element <PhoneField> can have a child component,  
i.e. <image/>, then in the xbl document you can define where a child  
can/should be rendered.

in xbl:
<PhoneField>
	<children includes="image"/>
	<text/>
</PhoneField>

in xul:
<PhoneField>
	<image src="ok.gif"/>
</PhoneField>

This would allow an image to be placed before the textbox, maybe  
indicating a valid/invalid number. The reason for scripts in the xbl  
document, is that you can define an accessor for PhoneField,  
PhoneField.value which returns the value of the textbox's value,  
without having to know the implementation of the PhoneField component  
e.g.(an image and text component). This may be beyond the luxor  
framework now or the future plans for luxor, but I thought it may be  
useful background.

I don't think a full implementation of xbl is appropriate, but some  
concepts, especially the idea of children may be appropriate. Compared  
to the idea of having an object tag, using an xbl derivative may be  
overly complicated, as the object tag is more straightforward, but I  
thought it was worth mentioning. I could see in luxor, an xbl  
derivative that could define new tags, but also assign a Java component  
to be used to render that tag as specified in the xbl document, as well  
as be able to wrap a set of predefined xul components to create new,  
more complex components.

Thoughts?

Blake

On Monday, July 7, 2003, at 05:48 PM, Gerald Bauer wrote:

> Hi Sam,
>
>> I know about tagdef, and I have a DTD for Luxor-XUL,
>> I don't know where
>> I got it, or if I made it myself.  I thought it came
>> with Luxor-XUL.
>
>   I put together a DTD for Luxor last December as far
> as I remember and it's up on the luxor-contrib site.
> However, it's only a snapshot and incomplete and it
> also can't handle inline XHTML.
>
>> The problem with tagdef is that verifying it can be
>> a problem.  If it
>> were something closer to:
>>
>> <tagdef class=net.sf.something.PhoneField"
>> name="phone"/>
>> <tag type="phone" id="phone1" color="red" />
>>
>> , then you could verify it much easier.
>>
>> In any case, since Luxor-XUL is open source, I'm
>> betting in a lot of
>> cases, like the phoneField, most people would
>> benefit from extending and
>> sharing, but there is always going to be some
>> component that only you
>> need, and no one wants to make the whole library
>> larger just for you. :)
>>
>> It's certainly something that probably should be
>> thought out, but maybe
>> the advantages of verification aren't as large as
>> the work involved.
>
>   I agree that something needs to be done so you can
> check if your XUL documents are valid. For now,
> however, it's a low priority for me. Anyone who want's
> to work on it is welcome.
>
>> I looked up the XBL spec on the W3C site.  It's
>> pretty much your
>> standard <!ELEMENT > <!ATTLIST > kind of tags.
>> Embedding the entire DTD
>> in the document would be silly, and I don't think
>> there is a standard
>> (at least I didn't see one) that covered augmenting
>> a DTD with more tags
>> when referencing an external DTD.
>
>    You might want to look into Relax Schemas,
> especially the compact syntax. DTD are pretty much a
> "legacy" and not a good choice for newer stuff.
>
>> Maybe I'll stop being so lazy and try to hack in the
>> ability to do it
>> this way as well, that way my verification scripts
>> won't complain about
>> tagdefs.  :)  I want to be able to give the GUI
>> designers what they need
>> to make a good GUI without bothering me to code it
>> in Swing.  It would
>> just make the entire process more effecient.
>
>   Again your contributions are welcome. I hope to get
> Beta 9 out soon.
>
>> I am very impressed and appreciative of the fact
>> that you considered
>> WebStart when making this project though.  How do
>> you plan on keeping it
>> that way with SWT, or do you?  I've never heard of
>> packaging native
>> libraries in a Web Start application, so I would be
>> interested in
>> knowing how to do this.
>
>   Please, check the mailinglist archive for an answer.
> For a start you might wonna read the IBM
> developerworks article titled "Deploy an SWT
> application using Java Web Start" @
> http://www-106.ibm.com/developerworks/opensource/library/os-jws/
>
>   - Gerald
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/ 
> 01
> _______________________________________________
> luxor-xul-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/luxor-xul-user
>



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.