Where would the ReadAndUpdate go with getter/setter methods? If you don't have methods don't we need the user to make the field public to be able to set/get it from outside??

I don't quite grok the objective of these annotations yet, I think. A little bit more context please?

Sanjiva.

Paul Fremantle wrote:
That's why I prefer having "ReadAndUpdate". I think its also really clear.

Paul

On Nov 20, 2007 1:06 PM, ant elder <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Looking pretty good. Could get away without the "ReadAndUpdate"
    annotation by using the individual read and update annotations on
    the same field, although that does mean having the xpath twice.

       ...ant


    On Nov 20, 2007 12:38 PM, Paul Fremantle <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:

        Aha

        That is quite cunning. So in other words, if you annotate the
        field then we assume to get it before execute and set it after.

        If you annotate the getter then we only get, annotate the setter
        we only set.

        I like the model, but I'd like to make the annotations match the
        action.

        So:
        @namespace(ns="http://fremantle.org);
        @ReadFromMessage(xpath="/ns:quote/Symbol")
        public void setSymbol(String symbol) {

        ...

        }

        @UpdateMessage(xpath="/")
        public OMElement getPayload() {
           // return an OMElement
        }

        @ReadAndUpdate(xpath="blah")
        String symbol = null;

        // expecting getters and setters:
        String getSymbol() { }
        void setSymbol(String s) { }

        Does that make sense?

        Since XPaths can logically refer to Strings, Booleans and
        Integers as well as XML, I suggest we support those as property
        types in the class too.

        Paul



        On Nov 20, 2007 12:30 PM, ant elder <[EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>> wrote:

            I'm not sure it needs a getter/setter generated or the type
            attribute specified on the property annottaion.  The
            @property annotation could be used on either a field or
            getter/setter method:

               @property(name="symbol")
               String value

            or

               @property(name="symbol")
               public void setValue(String s) {
                  value = s;
               }

            or

               @property(name="symbol")
               public String getValue() {
                  return value;
               }

            The annotation is associated with the field or method so the
            type can easily be introspected from that.

            Also, when the annotation is associated with a method you
            can see if its a getter or a setter so the action can be
            determined from the method name (get=out, set=in).

               ...ant


            On Nov 20, 2007 11:52 AM, Paul Fremantle <[EMAIL PROTECTED]
            <mailto:[EMAIL PROTECTED]>> wrote:

                Sorry that wasn't very clear was it!

                Basically, I thought one approach would be to add a name
                and type parameter to the
                @property tag

                @property(name="symbol", type="String|OMElement",....)

                and then (I'm assuming - based on my limited knowledge
                of annotations) we could automatically generate getters
                and setters.

                The problem with this approach is that the
                getters/setters would not be available for command
                completion in the IDE, so I ditched this idea.

                Paul


                On Nov 20, 2007 11:47 AM, ant elder <[EMAIL PROTECTED]
                <mailto:[EMAIL PROTECTED]>> wrote:



                    On Nov 20, 2007 11:44 AM, Paul Fremantle
                    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

                    <snip>


                            - the action could really be optional as its
                            not so hard for the runtime to see that the
                            value has been changed and set/getandset
would just be a performance optimisation
                        I guess so. It depends on whether we generate
                        the property and getters/setters or not. I was
                        kind of assuming that we wouldn't generate them.
                        Alternatively we could cache values before and
                        after the execute method, but thats a bit yucky,
                        I think its so simple to use an annotation, and
                        also since you get command completion for
                        annotations inside IDEs we can make it a
                        required property.

                    What do you mean by "generate the property and
                    getters/setters"?

                       ...ant




-- Paul Fremantle
                Co-Founder and VP of Technical Sales, WSO2
                OASIS WS-RX TC Co-chair

                blog: http://pzf.fremantle.org
                [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

                "Oxygenating the Web Service Platform", www.wso2.com
<http://www.wso2.com>




-- Paul Fremantle
        Co-Founder and VP of Technical Sales, WSO2
        OASIS WS-RX TC Co-chair

        blog: http://pzf.fremantle.org <http://pzf.fremantle.org>
        [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

        "Oxygenating the Web Service Platform", www.wso2.com
<http://www.wso2.com>




--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org <http://pzf.fremantle.org>
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

"Oxygenating the Web Service Platform", www.wso2.com <http://www.wso2.com>

--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to