cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: XObject
Date Mon, 04 Dec 2000 13:23:22 GMT
At 13:56 +0100 04/12/00, Sylvain Wallez wrote:
>Jeremy Quinn a crit :
>>
>> At 11:43 +0000 04/12/00, Paul Russell wrote:
>> >On Mon, Dec 04, 2000 at 11:13:33AM +0000, Jeremy Quinn wrote:
>> >> At 10:47 +0000 04/12/00, Paul Russell wrote:
>> >> >Works for me, although there was talk of calling it XObject2
>> >> >or something to remove any chance of people being confused...
>> >> For Cocoon 1, let's just bung some code into XSPPage.java where it checks
>> >> to see if it has an XObject .....
>> >> It could become something like .....
>> >>     // Convertible to DOM
>> >>     if (v instanceof org.apache.cocoon.xml.XObject){
>> >>       DocumentFragment fragment = factory.createDocumentFragment();
>> >>       ((org.apache.cocoon.xml.XObject) v).toDOM(fragment);
>> >>       return fragment;
>> >>     }
>> >>     if (v instanceof org.apache.cocoon.framework.XObject){
>> >>                      // issue depreciation warning, then output it anyway
>> >>       DocumentFragment fragment = factory.createDocumentFragment();
>> >>       ((org.apache.cocoon.framework.XObject) v).toDOM(fragment);
>> >>       return fragment;
>> >>     }
>> >> Does this help?
>> >
>> >Yep. That's fine - understood that. I think the discussion was
>> >more that having too classes called 'XObject' floating around
>> >might confuse logic sheet writers, rather than core developers!
>> >(Hey, we're already dealing with 23,000 lines of code - what's
>> >another object between friends :)
>>
>> OK, but there are probably more core developers than logicsheet writers :)
>>
>> So, if someone uses org.apache.cocoon.framework.XObject, in Cocoon 1 it
>> will still work. If they use it with Cocoon 2 they will get
>> compilation/depreciation errors on their XSP, is that not clear enough?
>>
>> Maybe the code for Cocoon 2 that handles XObject can issue a polite
>>warning ?
>>
>> If this is not suitable, we have to change the name.
>>
>> Sorry, I would -1 XObject2, just don't like names like that :<
>>
>> How about something like XInterface, XHandler, XSPObject?
>
>+1 for XSPObject (or XSPExprObject ?) because it clearly outlines its
>intended usage.
>


So I suggest this interface:

package org.apache.cocoon.xml;

import org.w3c.dom.Node;
import org.xml.sax.ContentHandler;


public interface XSPObject {
  /**
   * Generates SAX events representing the object's state
   * for the given content handler
   */
  public void toSAX(ContentHandler handler);

  /**
   * Appends children representing the object's state to
   * the given node
   */
  public void toDOM(Node node);

  /**
   * Returns a String representing the object's state
   * Used when the output of one TagLib is sent to the input of another,
	 * that does not handle XSPObject, or for setting Attributes, etc.
   */
  public String toString();
}
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

Mime
View raw message