Re: PlasticClass.getMethods() doesn't include introduced methods.
On 23 Apr 2012, at 16:50, Howard Lewis Ship wrote: > Often the introduced methods have privileged access to fields, > bypassing things like FieldConduits often, the introduced methods > are how the FieldConduits are themselves implemented. Not excluding > them from the field transformation step (where reads and writes of > fields are converted into invocations of introduced methods) could > yield infinite loops reading or writing fields! I see. > > In you situation, you could probably recode you approach using a > MethodAdvice on the introduced method, and use FieldHandles to > read/write the values. It will probably be easier than creating the > necessary bytecode using the changeImplementation(). > Thanks, I'll take a look at FieldHandles. I already have a pretty ugly fix for RadioGroup not having a defaultValidate method (is this a bug in its own right?). The other places where this looks like it might affect us are: 1) Creating a render phase method 2) Creating an event handler method - I guess I can fix this with TransformationSupport.addEventHandler(...). > changeImplementation() exists for the few things that can't be > addressed that way, and because I like to raise the bar higher in > terms of efficiency on things inside the framework that will be > replicated (hundreds of) thousands of times in an application. +1 to bar-raising! > > On Sat, Apr 21, 2012 at 5:12 AM, Luke Wilson-Mawer wrote: >> >> On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote: >> >>> On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson wrote: More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods. >>> >>> Ah, yes, I can see what you are going there. >>> >>> I think, perhaps, PlasticField and PlasticMethod may need a >>> makeVisible() method that makes the introduced members visible inside >>> PlasticClass.getMethods() and PlasticClass.getFields(). I don't think >>> there's a way to extricate things so that member access within the >>> introduced method is not transformed, but that's probably fine ... in >>> your case, you want to make sure that the ParameterWorker sees your >>> defaultValidate() method, and that method will be a stub with advice. >> >> What's the reason that introduced methods aren't visible by default like in >> in the old ClassTransformation? Are there consequences to just adding a line >> in PlasticClassImpl.createNewMethod() to add the new method onto the end of >> the methods list? I'm not all too familiar with the Plastic API but I could >> imagine using it for a whole bunch of things >> >>> >>> Kind regards, Luke - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator of Apache Tapestry >>> >>> The source for Tapestry training, mentoring and support. Contact me to >>> learn how I can get you up and productive in Tapestry fast! >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> Luke Wilson-Mawer >> Director, Viscri Limited >> l...@viscri.co.uk >> >> Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR >> Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX >> Registered number: 07031070 >> >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: PlasticClass.getMethods() doesn't include introduced methods.
Often the introduced methods have privileged access to fields, bypassing things like FieldConduits often, the introduced methods are how the FieldConduits are themselves implemented. Not excluding them from the field transformation step (where reads and writes of fields are converted into invocations of introduced methods) could yield infinite loops reading or writing fields! In you situation, you could probably recode you approach using a MethodAdvice on the introduced method, and use FieldHandles to read/write the values. It will probably be easier than creating the necessary bytecode using the changeImplementation(). changeImplementation() exists for the few things that can't be addressed that way, and because I like to raise the bar higher in terms of efficiency on things inside the framework that will be replicated (hundreds of) thousands of times in an application. On Sat, Apr 21, 2012 at 5:12 AM, Luke Wilson-Mawer wrote: > > On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote: > >> On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson wrote: >>> >>> More is described here: >>> http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods. >>> >> >> Ah, yes, I can see what you are going there. >> >> I think, perhaps, PlasticField and PlasticMethod may need a >> makeVisible() method that makes the introduced members visible inside >> PlasticClass.getMethods() and PlasticClass.getFields(). I don't think >> there's a way to extricate things so that member access within the >> introduced method is not transformed, but that's probably fine ... in >> your case, you want to make sure that the ParameterWorker sees your >> defaultValidate() method, and that method will be a stub with advice. > > What's the reason that introduced methods aren't visible by default like in > in the old ClassTransformation? Are there consequences to just adding a line > in PlasticClassImpl.createNewMethod() to add the new method onto the end of > the methods list? I'm not all too familiar with the Plastic API but I could > imagine using it for a whole bunch of things > >> >> >>> Kind regards, >>> >>> Luke >>> >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > Luke Wilson-Mawer > Director, Viscri Limited > l...@viscri.co.uk > > Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR > Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX > Registered number: 07031070 > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: PlasticClass.getMethods() doesn't include introduced methods.
On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote: > On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson wrote: >> >> More is described here: >> http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods. >> > > Ah, yes, I can see what you are going there. > > I think, perhaps, PlasticField and PlasticMethod may need a > makeVisible() method that makes the introduced members visible inside > PlasticClass.getMethods() and PlasticClass.getFields(). I don't think > there's a way to extricate things so that member access within the > introduced method is not transformed, but that's probably fine ... in > your case, you want to make sure that the ParameterWorker sees your > defaultValidate() method, and that method will be a stub with advice. What's the reason that introduced methods aren't visible by default like in in the old ClassTransformation? Are there consequences to just adding a line in PlasticClassImpl.createNewMethod() to add the new method onto the end of the methods list? I'm not all too familiar with the Plastic API but I could imagine using it for a whole bunch of things > > >> Kind regards, >> >> Luke >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > Luke Wilson-Mawer Director, Viscri Limited l...@viscri.co.uk Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX Registered number: 07031070
Re: PlasticClass.getMethods() doesn't include introduced methods.
On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson wrote: > Hi, > > The behaviour of the now deprecated ClassTransformation.matchMethods() and > related methods has changed to not include introduced Methods. I believe > this problem also applies to fields. > > On top of this, the built in ClassTransformationWorker2s use > PlasticClass.getMethods() directly to find fields. > > The sum total of this is that it is impossible to create a method or field in > a ClassTransformationWorker/ClassTransformationWorker2 and have it taken into > account by subsequent workers. Is this deliberate, or is it a bug? It's > causing us headaches in our upgrade to Tapestry 5.3. I think that's a use case that isn't accounted for. The other APIs on ClassTransformationWorker2, particularly TransformationSupport, are intended to fill the gap. My observation was that you would introduce a method to either add an event handler method, which can be done using TransformationSupport, or to introduce rendering behavior, which can be accomplished by advising one of the render phase methods. However, I'm interested in other use cases, and will certainly address them if they are valid. Sorry for your upgrade trouble; I'd have to say you are likely in the minority, using the most advanced features of Tapestry (and, unfortunately, paying the cost). That being said, I hope you are enjoying the Plastic API more than its various predecessors. > > More is described here: > http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods. > Ah, yes, I can see what you are going there. I think, perhaps, PlasticField and PlasticMethod may need a makeVisible() method that makes the introduced members visible inside PlasticClass.getMethods() and PlasticClass.getFields(). I don't think there's a way to extricate things so that member access within the introduced method is not transformed, but that's probably fine ... in your case, you want to make sure that the ParameterWorker sees your defaultValidate() method, and that method will be a stub with advice. > Kind regards, > > Luke > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
