xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Harlamov" <Alexey.Harla...@enterra-inc.com>
Subject RE: Separate CSS Engine?
Date Wed, 28 Jul 2004 10:30:10 GMT
Hello, All!

-----Original Message-----
From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
Sent: Wednesday, July 21, 2004 4:51 PM
To: Batik Users
Subject: Re: Separate CSS Engine?

>> 	I use Batik CSS engine to visualize XML documents. It can be
>> easily separated from other Batik packages. But there is a problem
with
>> it.
>> The CSS engine requires that DOM stylable elements implement the
>> CSSStylableElement interface.
>     Well, yah - otherwise how do you get at CSS?

>> In some cases it can't be realized, as DOM implementation can't be
>> modified.
>> In my situation I "hacked" the batik implementation to workaround the
>> problem. But it is not a clear way. It will be very helpful to
introduce
>> a special abstraction layer that allows use the engine with any DOM
>> implementation.
[skipped]

>     Why not just clone the document into the Batik DOM implementation
>and use that for CSS access?
	For performance reasons. It is not so lightweight operation on
large documents.

>> Something like Eclipse's adapters technique can be used. 
>     I'm not familar with these. Are they wrappers? Take an
>object and reference it for most stuff and add a few extra
>features. So you reference original node for getAttr, etc, but
>add getProperty and friends?
	In Eclipse Platform an adapters facility is used to add
functionality to objects. In any place you can request adapter of the
specified type for the given object. For example if I want to get CSS
support from an ordinary DOM element, I can do following:
Element elt = ...;
CSSStyleableElement styleable =
Platform.getAdapter(CSSStyleableElement.clsss, 
		elt);
if(styleable.isPseudoClass(...)){
}

The platform automatically create an adapter(wrapper) that allows to
work with the given DOM element as with a styleable element.

In Batik a something like following interface may be used to get service
from DOM.

public interface ICSSDOMService {
	boolean isPseudoClass(Element elt, String pseudo);
	
	StyleMap getComputedStyleMap(Element elt, String pseudoElement);

	void setComputedStyleMap(Element elt, String pseudoElement,
StyleMap sm);

	String getXMLId(Element elt);

	String getCSSClass(Element elt);

	URL getCSSBase(Element elt);
}

> 
> -----Original Message-----
> From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
> Sent: Monday, July 19, 2004 6:25 AM
> To: Batik Users
> Subject: Re: Separate CSS Engine?
> 
> Hi all,
> 
>    Like Cameron I think that this is essentially already done.
> The list of constants in CSSConstants is just for convenience,
> Except for a small number those constants aren't used by the
> CSSEngine.  You can easily configure your own subclass of
> CSSEngine to support any set of properties you want.
> 
>    I don't think the small space savings afforded by separating
> the constants is really all that useful but if someone wants to
> produce a patch they could.
> 
>    Since you say you have already applied the CSS engine to
> another XML grammar I suspect that I may be missing something
> important in your request.
> 
> Cameron McCormack wrote:
> 
> 
>>Jamie Browning:
>>
>>
>>>>However, as an XML utility, the CSS engine could stand alone.  
>>>>Applying CSS to an XML document is a general task, not limited to 
>>>>SVG.  A standalone CSS engine might be useful for other developers 
>>>>working with XML and CSS, using other XML dialects.
>>>>To achieve this, the properties supported by the engine would need
to
> 
> 
>>>>be decoupled, perhaps using some pluggable mechanism.
>>>
>>>I think this is an excellent idea.
>>
>>
>>And also not very difficult, since the CSS engine really isn't very
>>coupled to the rest of Batik.  See how the SVGCSSEngine class extends
>>the abstract CSSEngine to add the managers for all of the types that
> 
> SVG
> 
>>supports.
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message