Re: [shale] extending clay
Ha! Ya just had to throw that in didn't ya?!?! ;) -- James Mitchell 678.910.8017 On Oct 18, 2006, at 5:43 AM, Ted Husted wrote: Shale has its own list now: * http://shale.apache.org/mail-lists.html Along with a spiffy new logo :) -T. On 10/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi Did you ever do this Gary? Hermod -Original Message- From: Opstvedt, Hermod Sent: Monday, June 12, 2006 7:39 AM To: user@struts.apache.org Subject: RE: [shale] extending clay Hi Sounds like a great plugin. I guess one should wait until it is at a V1 stage before commiting (At least that is what I have done when committing to opensource), but if you someone to help you test it I would be more than willing. Hermod -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 7:07 PM To: Struts Users Mailing List Subject: Re: [shale] extending clay On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: <[EMAIL PROTECTED]> > > > > Hi > > > > What would be really nice is if you would make the plugin publically available. > > I was intending to make it available. I had intended to get some basic functionality working before I did so. Right now it is at the stage where it visits your eclipse project and parses all the clay config files. It attempts every xml file even those that are included in jars. If it is not a clay xml it just keeps chugging along. The reason I chose this approach over having to have the user point to clay configs is that I wanted it to 'just work'. Based on what it find it creates a tree view that mimics the inheritance of the components. Each node has an icon and a label (the jsfid) which have some pretty stock images (folder, resource) next to them. I was hoping to be able to incorporate more descriptive images, but images are not my speciality unfortunately. Maybe after I donate a graphic oriented person could enhance them. When you click a node the description from the clay xml is show below the tree. You can drag a component from the tree into a clay xml. At this point you enter a wizard that asks whether you want to create a new component extending the one that you dragged or whether you want to use the dragged component as a child element. You can also edit the description - the text area defaults to the description of the component you dragged. The wizard is not finished yet and I wanted it to be able to optionally run through the gamet of adding children, adding listeners, validators, etc. When you finish the wizard the component is dropped as xml into your config file. Eclipse resource change listeners are registered to make sure that when you save, delete, etc the visual component tree is updated. I also have an xml editor that supports auto complete based on the available clay components in your workspace. However, currently this has yet to be completely incorporated. I am fairly new to contributing to open source projects. Should I contribute the code in it's non-working state or wait until I get basic working plugin before I donate? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] extending clay
Shale has its own list now: * http://shale.apache.org/mail-lists.html Along with a spiffy new logo :) -T. On 10/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi Did you ever do this Gary? Hermod -Original Message- From: Opstvedt, Hermod Sent: Monday, June 12, 2006 7:39 AM To: user@struts.apache.org Subject: RE: [shale] extending clay Hi Sounds like a great plugin. I guess one should wait until it is at a V1 stage before commiting (At least that is what I have done when committing to opensource), but if you someone to help you test it I would be more than willing. Hermod -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 7:07 PM To: Struts Users Mailing List Subject: Re: [shale] extending clay On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: <[EMAIL PROTECTED]> > > > > Hi > > > > What would be really nice is if you would make the plugin publically available. > > I was intending to make it available. I had intended to get some basic functionality working before I did so. Right now it is at the stage where it visits your eclipse project and parses all the clay config files. It attempts every xml file even those that are included in jars. If it is not a clay xml it just keeps chugging along. The reason I chose this approach over having to have the user point to clay configs is that I wanted it to 'just work'. Based on what it find it creates a tree view that mimics the inheritance of the components. Each node has an icon and a label (the jsfid) which have some pretty stock images (folder, resource) next to them. I was hoping to be able to incorporate more descriptive images, but images are not my speciality unfortunately. Maybe after I donate a graphic oriented person could enhance them. When you click a node the description from the clay xml is show below the tree. You can drag a component from the tree into a clay xml. At this point you enter a wizard that asks whether you want to create a new component extending the one that you dragged or whether you want to use the dragged component as a child element. You can also edit the description - the text area defaults to the description of the component you dragged. The wizard is not finished yet and I wanted it to be able to optionally run through the gamet of adding children, adding listeners, validators, etc. When you finish the wizard the component is dropped as xml into your config file. Eclipse resource change listeners are registered to make sure that when you save, delete, etc the visual component tree is updated. I also have an xml editor that supports auto complete based on the available clay components in your workspace. However, currently this has yet to be completely incorporated. I am fairly new to contributing to open source projects. Should I contribute the code in it's non-working state or wait until I get basic working plugin before I donate? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] extending clay
Hi Did you ever do this Gary? Hermod -Original Message- From: Opstvedt, Hermod Sent: Monday, June 12, 2006 7:39 AM To: user@struts.apache.org Subject: RE: [shale] extending clay Hi Sounds like a great plugin. I guess one should wait until it is at a V1 stage before commiting (At least that is what I have done when committing to opensource), but if you someone to help you test it I would be more than willing. Hermod -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 7:07 PM To: Struts Users Mailing List Subject: Re: [shale] extending clay On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: <[EMAIL PROTECTED]> > > > > Hi > > > > What would be really nice is if you would make the plugin publically > > available. > > I was intending to make it available. I had intended to get some basic functionality working before I did so. Right now it is at the stage where it visits your eclipse project and parses all the clay config files. It attempts every xml file even those that are included in jars. If it is not a clay xml it just keeps chugging along. The reason I chose this approach over having to have the user point to clay configs is that I wanted it to 'just work'. Based on what it find it creates a tree view that mimics the inheritance of the components. Each node has an icon and a label (the jsfid) which have some pretty stock images (folder, resource) next to them. I was hoping to be able to incorporate more descriptive images, but images are not my speciality unfortunately. Maybe after I donate a graphic oriented person could enhance them. When you click a node the description from the clay xml is show below the tree. You can drag a component from the tree into a clay xml. At this point you enter a wizard that asks whether you want to create a new component extending the one that you dragged or whether you want to use the dragged component as a child element. You can also edit the description - the text area defaults to the description of the component you dragged. The wizard is not finished yet and I wanted it to be able to optionally run through the gamet of adding children, adding listeners, validators, etc. When you finish the wizard the component is dropped as xml into your config file. Eclipse resource change listeners are registered to make sure that when you save, delete, etc the visual component tree is updated. I also have an xml editor that supports auto complete based on the available clay components in your workspace. However, currently this has yet to be completely incorporated. I am fairly new to contributing to open source projects. Should I contribute the code in it's non-working state or wait until I get basic working plugin before I donate? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: [shale] extending clay
Hi Sounds like a great plugin. I guess one should wait until it is at a V1 stage before commiting (At least that is what I have done when committing to opensource), but if you someone to help you test it I would be more than willing. Hermod -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 7:07 PM To: Struts Users Mailing List Subject: Re: [shale] extending clay On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: <[EMAIL PROTECTED]> > > > > Hi > > > > What would be really nice is if you would make the plugin publically > > available. > > I was intending to make it available. I had intended to get some basic functionality working before I did so. Right now it is at the stage where it visits your eclipse project and parses all the clay config files. It attempts every xml file even those that are included in jars. If it is not a clay xml it just keeps chugging along. The reason I chose this approach over having to have the user point to clay configs is that I wanted it to 'just work'. Based on what it find it creates a tree view that mimics the inheritance of the components. Each node has an icon and a label (the jsfid) which have some pretty stock images (folder, resource) next to them. I was hoping to be able to incorporate more descriptive images, but images are not my speciality unfortunately. Maybe after I donate a graphic oriented person could enhance them. When you click a node the description from the clay xml is show below the tree. You can drag a component from the tree into a clay xml. At this point you enter a wizard that asks whether you want to create a new component extending the one that you dragged or whether you want to use the dragged component as a child element. You can also edit the description - the text area defaults to the description of the component you dragged. The wizard is not finished yet and I wanted it to be able to optionally run through the gamet of adding children, adding listeners, validators, etc. When you finish the wizard the component is dropped as xml into your config file. Eclipse resource change listeners are registered to make sure that when you save, delete, etc the visual component tree is updated. I also have an xml editor that supports auto complete based on the available clay components in your workspace. However, currently this has yet to be completely incorporated. I am fairly new to contributing to open source projects. Should I contribute the code in it's non-working state or wait until I get basic working plugin before I donate? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [shale] extending clay
On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Ryan Wynn" <[EMAIL PROTECTED]> > > On 6/7/06, Gary VanMatre wrote: > > >From: > > > > > > Hi > > > > > > What would be really nice is if you would make the plugin publically > available. > > > > > I was intending to make it available. I had intended to get some > basic functionality working before I did so. Right now it is at the > stage where it visits your eclipse project and parses all the clay > config files. It attempts every xml file even those that are included > in jars. If it is not a clay xml it just keeps chugging along. The > reason I chose this approach over having to have the user point to > clay configs is that I wanted it to 'just work'. Based on what it > find it creates a tree view that mimics the inheritance of the > components. Each node has an icon and a label (the jsfid) which have > some pretty stock images (folder, resource) next to them. I was > hoping to be able to incorporate more descriptive images, but images > are not my speciality unfortunately. Maybe after I donate a graphic > oriented person could enhance them. > > When you click a node the description from the clay xml is show below > the tree. You can drag a component from the tree into a clay xml. At > this point you enter a wizard that asks whether you want to create a > new component extending the one that you dragged or whether you want > to use the dragged component as a child element. You can also edit > the description - the text area defaults to the description of the > component you dragged. The wizard is not finished yet and I wanted it > to be able to optionally run through the gamet of adding children, > adding listeners, validators, etc. When you finish the wizard the > component is dropped as xml into your config file. Eclipse resource > change listeners are registered to make sure that when you save, > delete, etc the visual component tree is updated. > > I also have an xml editor that supports auto complete based on the > available clay components in your workspace. However, currently this > has yet to be completely incorporated. > > I am fairly new to contributing to open source projects. Should I > contribute the code in it's non-working state or wait until I get > basic working plugin before I donate? > That's a fair question. I know that if you want to donate it here, you will be asked to sign a CLA (http://www.apache.org/licenses/#clas). Another consideration is that the donation doesn't give you commit rights meaning that if you contribute it, you will have to work on it by submitting patches until you earn your karam. This is how I earned mine. They just got sick of me submitting patches :--) Martin, Ted or Craig would give a better summary on the apache way. I think you just described how 80-90% of Apache committers first earned that right :-). I'd like to see it here. We do have the shale-designtime project for Creator. Me too ... that would be a very nice addition. Gary > Thanks, > Ryan Craig > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [shale] extending clay
Shale ticket http://issues.apache.org/struts/browse/SHALE-187 created for this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] extending clay
>From: "Ryan Wynn" <[EMAIL PROTECTED]> > > On 6/7/06, Gary VanMatre wrote: > > >From: > > > > > > Hi > > > > > > What would be really nice is if you would make the plugin publically > available. > > > > > I was intending to make it available. I had intended to get some > basic functionality working before I did so. Right now it is at the > stage where it visits your eclipse project and parses all the clay > config files. It attempts every xml file even those that are included > in jars. If it is not a clay xml it just keeps chugging along. The > reason I chose this approach over having to have the user point to > clay configs is that I wanted it to 'just work'. Based on what it > find it creates a tree view that mimics the inheritance of the > components. Each node has an icon and a label (the jsfid) which have > some pretty stock images (folder, resource) next to them. I was > hoping to be able to incorporate more descriptive images, but images > are not my speciality unfortunately. Maybe after I donate a graphic > oriented person could enhance them. > > When you click a node the description from the clay xml is show below > the tree. You can drag a component from the tree into a clay xml. At > this point you enter a wizard that asks whether you want to create a > new component extending the one that you dragged or whether you want > to use the dragged component as a child element. You can also edit > the description - the text area defaults to the description of the > component you dragged. The wizard is not finished yet and I wanted it > to be able to optionally run through the gamet of adding children, > adding listeners, validators, etc. When you finish the wizard the > component is dropped as xml into your config file. Eclipse resource > change listeners are registered to make sure that when you save, > delete, etc the visual component tree is updated. > > I also have an xml editor that supports auto complete based on the > available clay components in your workspace. However, currently this > has yet to be completely incorporated. > > I am fairly new to contributing to open source projects. Should I > contribute the code in it's non-working state or wait until I get > basic working plugin before I donate? > That's a fair question. I know that if you want to donate it here, you will be asked to sign a CLA (http://www.apache.org/licenses/#clas). Another consideration is that the donation doesn't give you commit rights meaning that if you contribute it, you will have to work on it by submitting patches until you earn your karam. This is how I earned mine. They just got sick of me submitting patches :--) Martin, Ted or Craig would give a better summary on the apache way. I'd like to see it here. We do have the shale-designtime project for Creator. Gary > Thanks, > Ryan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [shale] extending clay
>From: "Ryan Wynn" <[EMAIL PROTECTED]> >> On 6/6/06, Gary VanMatre <[EMAIL PROTECTED]>wrote: > > >From: "Ryan Wynn" <[EMAIL PROTECTED]>> > > I have had to work around the use of private instance variables in a > > > couple other scenarios in trying to build this plugin. I was just > > > wondering if anyone was opposed to changing some of these instance > > > variables to protected or adding protected accessors. > > > > > > > That seems very reasonable. It might be easier if you just created a JIRA svn > patch but if you can't do that for whatever reason, I can make the changes. > > > > Just wanted to get your feedback before I created a JIRA ticket. I > just got it working but had to resort to copy and paste of the clay > code + some of my changes. Basically I found out that instead of just > be
ing ab
le to extend configureRules I needed to weave in digester > rules throughout the existing code. I also needed to extend all the > ComponentBeans to provide a description attribute. > > What I am trying to do would be easier if the base ComponentBean class > had a description attribute. Would it be bad to create this attribute > and not 'digest' it under normal runtime circumstances but make it > available to tooling? >
That seems reasonable in this case since the "description" is part of the DTD.
We could just provide a boolean property to toggle on reading the descriptions
and add the property to all the config beans.
We need to create a JIRA ticket so we can track the change regardless.
Gary
> This could be accompanied by a flag on the ClayXmlParser indicated > that the descriptions should be digested. It could default to false, > but tooling could override to true. > > Attached is my modified ClayXmlParser which digests description > elements and sets them into extended ComponentBeans. > > > > > > Thanks, > > > Ryan > > > > > > > Gary > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
--- Begin Message ---
package clay_plugin.parser;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.Rule;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shale.clay.config.ClayConfigParser;
import org.apache.shale.clay.config.ClayConfigureListener;
import org.apache.shale.clay.config.beans.ComponentBean;
import org.apache.shale.clay.config.beans.ComponentConfigBean;
import org.apache.shale.clay.config.beans.ConfigBean;
import org.apache.shale.util.Messages;
import org.xml.sax.Attributes;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
/**
*
* This class loads the configuration files defining page fragments and caches a
* graph of beans in application scope. The location of the default
* configuration file is located at
* Globals.DEFAULT_CLAY_CONFIG_FILE. A comma value list of names
* can be supplied as a initialization parameter in the web deployment
* descriptor using the parameter name Globals.CLAY_CONFIG_FILES.
*
*/
public class ClayXmlParserExt implements ClayConfigParser {
/**
*
* The [EMAIL PROTECTED] ComponentConfigBean} is the container holding all of the
* component metadata definitions read for the configuration files.
*
*/
private ConfigBean config = null;
/**
*
* The Digester makes short work of materalizing a XML
* document into an object graph using simple binding rules.
*
*/
private Digester digester;
/**
*
* Commons logging utility object static instance.
*
*/
private static Log log;
static {
log = LogFactory
.getLog(org.apache.shale.clay.config.ClayXmlParser.class);
}
/**
* @return config [EMAIL PROTECTED] ConfigBean} instance of the component metadata
* container
*/
public ConfigBean getConfig() {
return config;
}
/**
* @param config
*[EMAIL PROTECTED] ConfigBean} instance of the component metadata
*container
*/
public void setConfig(ConfigBean config) {
this.config = config;
}
/**
*
* Message resources for this class.
*
*/
private static Messages messages = new Messages(
"org.apache.shale.clay.Bundle", ClayConfigureListener.class
.getClassLoader());
/**
*
* A static array of local DTD's to validate the digested documents against
* when not connected to the internet.
*
*/
protected Object[] registrations = { new String[] {
"-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN",
"/org/apache/shale/clay/config/clay-config_1_0.dtd" } };
/**
*
* This is a custom digester Rule that handles adding value pairs to the
* symbols table on the [EMAIL PROTECTED] ComponentBean} nodes.
*
*/
private class SymbolRule extends Rule {
/**
*
* Takes a peek at the last object on the dig
Re: [shale] extending clay
On 6/7/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: <[EMAIL PROTECTED]> > > Hi > > What would be really nice is if you would make the plugin publically available. > I was intending to make it available. I had intended to get some basic functionality working before I did so. Right now it is at the stage where it visits your eclipse project and parses all the clay config files. It attempts every xml file even those that are included in jars. If it is not a clay xml it just keeps chugging along. The reason I chose this approach over having to have the user point to clay configs is that I wanted it to 'just work'. Based on what it find it creates a tree view that mimics the inheritance of the components. Each node has an icon and a label (the jsfid) which have some pretty stock images (folder, resource) next to them. I was hoping to be able to incorporate more descriptive images, but images are not my speciality unfortunately. Maybe after I donate a graphic oriented person could enhance them. When you click a node the description from the clay xml is show below the tree. You can drag a component from the tree into a clay xml. At this point you enter a wizard that asks whether you want to create a new component extending the one that you dragged or whether you want to use the dragged component as a child element. You can also edit the description - the text area defaults to the description of the component you dragged. The wizard is not finished yet and I wanted it to be able to optionally run through the gamet of adding children, adding listeners, validators, etc. When you finish the wizard the component is dropped as xml into your config file. Eclipse resource change listeners are registered to make sure that when you save, delete, etc the visual component tree is updated. I also have an xml editor that supports auto complete based on the available clay components in your workspace. However, currently this has yet to be completely incorporated. I am fairly new to contributing to open source projects. Should I contribute the code in it's non-working state or wait until I get basic working plugin before I donate? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] extending clay
>From: <[EMAIL PROTECTED]> > > Hi > > What would be really nice is if you would make the plugin publically > available. > +1 :-) > > Hermod > > -Original Message- > From: Ryan Wynn [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 5:11 AM > To: Struts User > Subject: [shale] extending clay > > > I'm writing an eclipse plugin to create a visual builder for clay > components. What I would like to do is extend the ClayXmlParser to > add a rule that will capture the description from the xml and set in > into the ComponentBean. The reason I want to be able to do this is to > display the description of each component in the visual builder. > > Currently, the ClayXmlParser's configureRules method is protected > which is a simple hook for me. However, the digester instance is > private and there are no public/protected accessors. > > I have had to work around the use of private instance variables in a > couple other scenarios in trying to build this plugin. I was just > wondering if anyone was opposed to changing some of these instance > variables to protected or adding protected accessors. > > Thanks, > Ryan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > This email with attachments is solely for the use of the individual or > entity to whom it is addressed. Please also be aware that the DnB NOR Group > cannot accept any payment orders or other legally binding correspondence with > customers as a part of an email. > > This email message has been virus checked by the anti virus programs used > in the DnB NOR Group. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >
RE: [shale] extending clay
Hi What would be really nice is if you would make the plugin publically available. Hermod -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 5:11 AM To: Struts User Subject: [shale] extending clay I'm writing an eclipse plugin to create a visual builder for clay components. What I would like to do is extend the ClayXmlParser to add a rule that will capture the description from the xml and set in into the ComponentBean. The reason I want to be able to do this is to display the description of each component in the visual builder. Currently, the ClayXmlParser's configureRules method is protected which is a simple hook for me. However, the digester instance is private and there are no public/protected accessors. I have had to work around the use of private instance variables in a couple other scenarios in trying to build this plugin. I was just wondering if anyone was opposed to changing some of these instance variables to protected or adding protected accessors. Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [shale] extending clay
Attached is my modified ClayXmlParser which digests description
elements and sets them into extended ComponentBeans.
My mistake, forgot to add digester rules for attributes and symbols.
Attached is the fixed version.
package clay_plugin.parser;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.Rule;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shale.clay.config.ClayConfigParser;
import org.apache.shale.clay.config.ClayConfigureListener;
import org.apache.shale.clay.config.beans.ComponentBean;
import org.apache.shale.clay.config.beans.ComponentConfigBean;
import org.apache.shale.clay.config.beans.ConfigBean;
import org.apache.shale.util.Messages;
import org.xml.sax.Attributes;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
/**
*
* This class loads the configuration files defining page fragments and caches a
* graph of beans in application scope. The location of the default
* configuration file is located at
* Globals.DEFAULT_CLAY_CONFIG_FILE. A comma value list of names
* can be supplied as a initialization parameter in the web deployment
* descriptor using the parameter name Globals.CLAY_CONFIG_FILES.
*
*/
public class ClayXmlParserExt implements ClayConfigParser {
/**
*
* The [EMAIL PROTECTED] ComponentConfigBean} is the container holding all of the
* component metadata definitions read for the configuration files.
*
*/
private ConfigBean config = null;
/**
*
* The Digester makes short work of materalizing a XML
* document into an object graph using simple binding rules.
*
*/
private Digester digester;
/**
*
* Commons logging utility object static instance.
*
*/
private static Log log;
static {
log = LogFactory
.getLog(org.apache.shale.clay.config.ClayXmlParser.class);
}
/**
* @return config [EMAIL PROTECTED] ConfigBean} instance of the component metadata
* container
*/
public ConfigBean getConfig() {
return config;
}
/**
* @param config
*[EMAIL PROTECTED] ConfigBean} instance of the component metadata
*container
*/
public void setConfig(ConfigBean config) {
this.config = config;
}
/**
*
* Message resources for this class.
*
*/
private static Messages messages = new Messages(
"org.apache.shale.clay.Bundle", ClayConfigureListener.class
.getClassLoader());
/**
*
* A static array of local DTD's to validate the digested documents against
* when not connected to the internet.
*
*/
protected Object[] registrations = { new String[] {
"-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN",
"/org/apache/shale/clay/config/clay-config_1_0.dtd" } };
/**
*
* This is a custom digester Rule that handles adding value pairs to the
* symbols table on the [EMAIL PROTECTED] ComponentBean} nodes.
*
*/
private class SymbolRule extends Rule {
/**
*
* Takes a peek at the last object on the digester stack. It assume that
* it will be a [EMAIL PROTECTED] ComponentBean}. The attributes "name" and
* "value" are pulled from the Attributes sax collection
* and pushed into the [EMAIL PROTECTED] ComponentBean}'s symbols
* Map collection. The character '@' is prepended to the symbol name if
* not existing.
*
*/
public void begin(String qname, String name, Attributes attributes)
throws Exception {
ComponentBean b = (ComponentBean) super.digester.peek();
if (b != null && attributes != null) {
String key = attributes.getValue("name");
String value = attributes.getValue("value");
if (name != null) {
StringBuffer tmp = new StringBuffer(key);
if (tmp.charAt(0) != '@')
tmp.insert(0, '@');
b.addSymbol(tmp.toString(), value);
}
}
}
}
/**
*
* Loads a configuration file from a url. The input stream
* is identifed by the watchDogName.
*
*/
public void loadConfigFile(URL configURL, String watchDogName)
throws IOException, SAXException {
if (digester == null) {
digester = new Digester();
digester.setLogger(log);
digester.setValidating(true);
digester.setUseContextClassLoader(true);
// Register our local copy of the DTDs that we can find
for (int i = 0; i < registrations.length; i++) {
URL url = this.getClass().getResource(
((String[]) registrations[i])[1]);
if (url != null) {
digester.register(((String[]) registrations[i])[0], url
.toString());
}
}
configureRules();
digester.push(config);
} else {
digester.clear();
digester.push(config);
}
InputStream in = null;
InputSource inputSource = null;
try {
in = configURL.openStream();
inputSource = new InputSource(configURL.toExternalForm());
inputSource.setByteStream(in);
digester.parse(inputSource);
} finally {
if (in != null)
Re: [shale] extending clay
On 6/6/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Ryan Wynn" <[EMAIL PROTECTED]>
> I have had to work around the use of private instance variables in a
> couple other scenarios in trying to build this plugin. I was just
> wondering if anyone was opposed to changing some of these instance
> variables to protected or adding protected accessors.
>
That seems very reasonable. It might be easier if you just created a JIRA svn
patch but if you can't do that for whatever reason, I can make the changes.
Just wanted to get your feedback before I created a JIRA ticket. I
just got it working but had to resort to copy and paste of the clay
code + some of my changes. Basically I found out that instead of just
being able to extend configureRules I needed to weave in digester
rules throughout the existing code. I also needed to extend all the
ComponentBeans to provide a description attribute.
What I am trying to do would be easier if the base ComponentBean class
had a description attribute. Would it be bad to create this attribute
and not 'digest' it under normal runtime circumstances but make it
available to tooling?
This could be accompanied by a flag on the ClayXmlParser indicated
that the descriptions should be digested. It could default to false,
but tooling could override to true.
Attached is my modified ClayXmlParser which digests description
elements and sets them into extended ComponentBeans.
> Thanks,
> Ryan
>
Gary
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
package clay_plugin.parser;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.Rule;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shale.clay.config.ClayConfigParser;
import org.apache.shale.clay.config.ClayConfigureListener;
import org.apache.shale.clay.config.beans.ComponentBean;
import org.apache.shale.clay.config.beans.ComponentConfigBean;
import org.apache.shale.clay.config.beans.ConfigBean;
import org.apache.shale.util.Messages;
import org.xml.sax.Attributes;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
/**
*
* This class loads the configuration files defining page fragments and caches a
* graph of beans in application scope. The location of the default
* configuration file is located at
* Globals.DEFAULT_CLAY_CONFIG_FILE. A comma value list of names
* can be supplied as a initialization parameter in the web deployment
* descriptor using the parameter name Globals.CLAY_CONFIG_FILES.
*
*/
public class ClayXmlParserExt implements ClayConfigParser {
/**
*
* The [EMAIL PROTECTED] ComponentConfigBean} is the container holding all of the
* component metadata definitions read for the configuration files.
*
*/
private ConfigBean config = null;
/**
*
* The Digester makes short work of materalizing a XML
* document into an object graph using simple binding rules.
*
*/
private Digester digester;
/**
*
* Commons logging utility object static instance.
*
*/
private static Log log;
static {
log = LogFactory
.getLog(org.apache.shale.clay.config.ClayXmlParser.class);
}
/**
* @return config [EMAIL PROTECTED] ConfigBean} instance of the component metadata
* container
*/
public ConfigBean getConfig() {
return config;
}
/**
* @param config
*[EMAIL PROTECTED] ConfigBean} instance of the component metadata
*container
*/
public void setConfig(ConfigBean config) {
this.config = config;
}
/**
*
* Message resources for this class.
*
*/
private static Messages messages = new Messages(
"org.apache.shale.clay.Bundle", ClayConfigureListener.class
.getClassLoader());
/**
*
* A static array of local DTD's to validate the digested documents against
* when not connected to the internet.
*
*/
protected Object[] registrations = { new String[] {
"-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN",
"/org/apache/shale/clay/config/clay-config_1_0.dtd" } };
/**
*
* This is a custom digester Rule that handles adding value pairs to the
* symbols table on the [EMAIL PROTECTED] ComponentBean} nodes.
*
*/
private class SymbolRule extends Rule {
/**
*
* Takes a peek at the last object on the digester stack. It assume that
* it will be a [EMAIL PROTECTED] ComponentBean}. The attributes "name" and
* "value" are pulled from the Attributes sax collection
* and pushed into the [EMAIL PROTECTED] ComponentBean}'s symbols
* Map collection. The character '@' is prepended to the symbol name if
* not existing.
*
*/
public void begin(String qname, String name, Attributes attributes)
throws Exception {
ComponentBean b = (ComponentBean
Re: [shale] extending clay
>From: "Ryan Wynn" <[EMAIL PROTECTED]> > > I'm writing an eclipse plugin to create a visual builder for clay > components. What I would like to do is extend the ClayXmlParser to > add a rule that will capture the description from the xml and set in > into the ComponentBean. The reason I want to be able to do this is to > display the description of each component in the visual builder. > Sounds pretty cool :--) > Currently, the ClayXmlParser's configureRules method is protected > which is a simple hook for me. However, the digester instance is > private and there are no public/protected accessors. > > I have had to work around the use of private instance variables in a > couple other scenarios in trying to build this plugin. I was just > wondering if anyone was opposed to changing some of these instance > variables to protected or adding protected accessors. > That seems very reasonable. It might be easier if you just created a JIRA svn patch but if you can't do that for whatever reason, I can make the changes. > Thanks, > Ryan > Gary > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
[shale] extending clay
I'm writing an eclipse plugin to create a visual builder for clay components. What I would like to do is extend the ClayXmlParser to add a rule that will capture the description from the xml and set in into the ComponentBean. The reason I want to be able to do this is to display the description of each component in the visual builder. Currently, the ClayXmlParser's configureRules method is protected which is a simple hook for me. However, the digester instance is private and there are no public/protected accessors. I have had to work around the use of private instance variables in a couple other scenarios in trying to build this plugin. I was just wondering if anyone was opposed to changing some of these instance variables to protected or adding protected accessors. Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
