Re: New Tag - Looking for Comments (Maintain user code during regeneration of files)

[Paul Libbrecht]

Jason,






I suppose jelly could have advantage out of that.
I am convinced xslt's may have one as well.

paul



Le 17-juil.-09 à 05:11, Jason Weinstein a écrit :

A matter of protocol: what you describe is somewhat out of the world of any applicable library, I feel... or is it for jelly? please put the right subject and do not "steal threads" by answering a mail into another topic. The thing you describe seems to be somewhat of a possibly useful pattern to be able to bring back changes on generated files where it is easier to make (nothing to do with java code btw) into a source. It is not a tag only though! It definitely is something that would remanipulate the source (be it xml, xsl, jelly or any other) based on the output.

This simple tag eliminates a portion of this problem.

A simple example:

Template:

<?xml version="1.0"?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:s="jelly:slot">
import org.apache.commons.jelly.JellyTagException;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;

public class ${className} extends TagSupport {
    public void doTag(XMLOutput output) throws JellyTagException {

        getBody().run(context, output);
        </s:slot>
    }
}
</j:jelly>

Outputs:

import org.apache.commons.jelly.JellyTagException;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;

public class FooTag extends TagSupport {
    public void doTag(XMLOutput output) throws JellyTagException {
        //[[100]] - user code
        getBody().run(context, output);
        //[[100]] - user code
    }
}



    public void doTag(XMLOutput output) throws JellyTagException {
        //[[100]] - user code
        System.out.println("entering doTag");
        getBody().run(context, output);
        //[[100]] - user code
    }







        getBody().run(context, output);
        </s:slot>





Lauren found her dream laptop. Find the PC that’s right for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

A common problem with templating systems is that they overwrite changes made to the generated files, when things are regenerated. <s:slot id="//[[100]] - user code" overwrite="false" evaluate="true" buffer="${fileText}"> If the user now changes this file and adds a print statement the statement will survive regeneration. This tag allows the user to make changes in between unique id tags in the generated file and to have those changes persist after regeneration. Obvious issues exist in the above example when parameter names or numbers change. However if a generate and compile step are combined this will give an early clue that the user code will need to be changed. Basically it is using the generated file as a Context (Key, Vals) for regenerated files. <s:slot id="//[[100]] - user code" overwrite="false" evaluate="true" buffer="${fileText}"> The id is the key, overwrite indicates whether the code in between should be overwritten, evaluate indicates whether the code in between should be evaled as a script (only for new files) and the buffer contains the original text of the file being regenerated. If anyone has any ideas on improving this simple code i'd be glad to hear suggestions. The code was done very quickly so even simple suggestions may be helpful. Changes to inputs, names, types, etc...

smime.p7s
Description: S/MIME cryptographic signature