Re: Is fireModelChanged mandatory ?
Christian Cryder <[email protected]> Sat, 17 Sep 2005 10:57:58 -0400
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1126969131-5037-23 Content-Type: multipart/alternative; boundary="------------050406040409040801060907" This is a multi-part message in MIME format. --------------050406040409040801060907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Franck Routier wrote: > > > Hi Christian, > > What is cool is Diez work is that the FormMap acts also as a > TempalteModel for the form. That's what I am doing as well. Ah, ok, that helps, and yes it is a good idea (I think). Couple of options... 1. Extend from AbstractTemplateModel or AbstractIterativeTemplateModel and have those implement FormMap (probably just delegate to an underlying FormMap, rather than reimplement the FormMap functionality) 2. Extend from FormMap and have that implement AbstractTemplateModel and/or AbstractIterativeTemplateModel (either through 2a) delegation to an underlying instance of template model or 2b) actually reimplementing the template model logic) It sounds to me like you are trying to take the 2b approach right now. This seems like the hardest route to me, since it will get challenging to handle both types of template model, and then if something in the bmvc template model implementation changes your code will need to change to or else it will be broken. So I'd recommend pursuing a delegation pattern if at all possible (either 1 or 2a), rather than reimplementing the logic yourself (2b). If you do this, you won't have to worry about the fireModelChanged thing (the delegate will take care of it for you). Now in terms of deciding between 1 and 2a, one thing to point out is that the template model stuff is probably more complicated because it works with the component model (it has event notification, etc). So I'd be more inclined to start with the template model and extend that to support form map (1), rather than vica-versa (2). So what about this - why not create 2 classes, one (AbstractFormMapTemplateModel) which extends from AbstractTemplateModel, has setFormMap(FormMap) / getFormMap() methods, and implements the FormMap interface. This allows you to extend from this model and simply "plug in" a form map into the template model. Then you could create a second class (AbstractIterativeFormMapTemplateModel) which extends from the first and thus gets the form map support from it. Then again, it might be easier to start from the other direction. I'm just not sure - you are probably going to have to experiment to see which works best. I think the key is going to be to use a delegation pattern, rather than re-implementing directly, as this will mean you won't have to worry about the internals of either template model or form map. One of the advantages of trying to merge form map and template model is that it gives you the programmer one object to work with, which may seem to make things easier. The disadvantage in doing this however is that you are basically conflating two distinct layers back into one - so you end up with a hybrid object that requires both layers, rather than two nicely separated layers that can each work independently of each other. This conflation is why the options get complicated as you start trying to figure out how to merge them. So on second thought, maybe its not such a good idea after all :-) I'm not saying you shouldn't do it, mind you - definitely try it out (preferably both ways) and see which works better, and then compare with what it would look like just keeping things separate (eg. your code has a refernce to the form map, and a reference to the template model, and it just uses each when it needs them). I'm rambiling now because the more I think about it the more I see alternate avenues to explore. So I'll shut up before I futher confuse things... Does this help at all? Christian > > So I have to re-implement both FormMap and TemplateModel in my > class... I choosed to extend from FormMap as it seems to me is does > quite a lot of things, so what I have to is implement TemplateModel, > that is TemplateModel itself, Model and Contextual. > > None of these interfaces specifies a fireModelChanged method. But all > implementations have it ! > > So my question is finally : should I implement it also ? If so, why > isn't it part of Model interface ? > > Thanks a lot, > > Franck > > > Le 16 sept. 05, à 22:54, Christian Cryder a écrit : > > If you are implementing by extending from one of the abstract > implementations, then you won't need to. If you are implementing > from scratch, then should look at the abstract implementations for > guidance. > > Typically, all the end programmer needs to do is the former, not > the latter. But I don't know exactly what you are doing so I can't > say for sure... > > That help? If you are still unsure, send some more info and I will > try and answer it better for your specific needs. > > Christian > > Franck Routier wrote:So, if I'm implementing Model interface, > should I add such a method (cut and paste from say > DefaultTemplateModel), although it is not really part of the > interface contract ? > > > > Le 16 sept. 05, à 15:40, Christian Cryder a écrit : > > > > fireModelChanged is an internal method - you should never > need to invoke it. Basically, it is defined in the various > model implementations - when you change data to the model > (eg. adding data, removing data, etc), then the model > notifies any listeners "hey, something has happened - > better refresh yourselves" > > So this method is an internal communication mechanism for > models to talk to the components that use them. > > THat help? > > Christian > > Franck Routier wrote:Hi Barracudans, > > > I was just wondering if / where fireModelChanged is > defined ? > Is it defined in an interface ? > > I which to implement TemplateModel, which means also > implementing Model and Contextual, but I cannot see > fireModelChanged anywhere. However, all > AbstractxxxModel I see are providing a > fireModelChanged() method. > > I was just wondering what this is for, and why it's > not defined in the interfaces if mandatory. > > Thanks, > > Franck > > > > -- > Barracuda mailing list > [email protected] > http://www.objectweb.org/wws/lists/projects/barracuda > > > > -- > Christian Cryder > Internet Architect, ATMReports.com > > /"Coffee? I could quit anytime, just not today"/ > /http://seelifedifferently.blogspot.com/ > > > -- > > Barracuda mailing list > > [email protected] > > http://www.objectweb.org/wws/lists/projects/barracuda > > > > -- > Barracuda mailing list > [email protected] > http://www.objectweb.org/wws/lists/projects/barracuda > > > > -- > Christian Cryder > Internet Architect, ATMReports.com > > /"Coffee? I could quit anytime, just not today"/ > /http://seelifedifferently.blogspot.com/ > > > -- > > Barracuda mailing list > > [email protected] > > http://www.objectweb.org/wws/lists/projects/barracuda > >------------------------------------------------------------------------ > > >-- >Barracuda mailing list >[email protected] >http://www.objectweb.org/wws/lists/projects/barracuda > > -- ------------------------------------------------------------------------ Christian Cryder Internet Architect, ATMReports.com <http://atmreports.com> ------------------------------------------------------------------------ /"Coffee? I could quit anytime, just not today" http://seelifedifferently.blogspot.com/ --------------050406040409040801060907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Franck Routier wrote: <blockquote cite="[email protected]" type="cite"><br> <br> Hi Christian, <br> <br> What is cool is Diez work is that the FormMap acts also as a TempalteModel for the form. That's what I am doing as well. <br> </blockquote> Ah, ok, that helps, and yes it is a good idea (I think). Couple of options...<br> <br> 1. Extend from AbstractTemplateModel or AbstractIterativeTemplateModel and have those implement FormMap (probably just delegate to an underlying FormMap, rather than reimplement the FormMap functionality)<br> <br> 2. Extend from FormMap and have that implement AbstractTemplateModel and/or AbstractIterativeTemplateModel (either through 2a) delegation to an underlying instance of template model or 2b) actually reimplementing the template model logic)<br> <br> It sounds to me like you are trying to take the 2b approach right now. This seems like the hardest route to me, since it will get challenging to handle both types of template model, and then if something in the bmvc template model implementation changes your code will need to change to or else it will be broken.<br> <br> So I'd recommend pursuing a delegation pattern if at all possible (either 1 or 2a), rather than reimplementing the logic yourself (2b). If you do this, you won't have to worry about the fireModelChanged thing (the delegate will take care of it for you).<br> <br> Now in terms of deciding between 1 and 2a, one thing to point out is that the template model stuff is probably more complicated because it works with the component model (it has event notification, etc). So I'd be more inclined to start with the template model and extend that to support form map (1), rather than vica-versa (2).<br> <br> So what about this - why not create 2 classes, one (AbstractFormMapTemplateModel) which extends from AbstractTemplateModel, has setFormMap(FormMap) / getFormMap() methods, and implements the FormMap interface. This allows you to extend from this model and simply "plug in" a form map into the template model. Then you could create a second class (AbstractIterativeFormMapTemplateModel) which extends from the first and thus gets the form map support from it.<br> <br> Then again, it might be easier to start from the other direction. I'm just not sure - you are probably going to have to experiment to see which works best.<br> <br> I think the key is going to be to use a delegation pattern, rather than re-implementing directly, as this will mean you won't have to worry about the internals of either template model or form map.<br> <br> One of the advantages of trying to merge form map and template model is that it gives you the programmer one object to work with, which may seem to make things easier. The disadvantage in doing this however is that you are basically conflating two distinct layers back into one - so you end up with a hybrid object that requires both layers, rather than two nicely separated layers that can each work independently of each other. This conflation is why the options get complicated as you start trying to figure out how to merge them. <br> <br> So on second thought, maybe its not such a good idea after all :-)<br> <br> I'm not saying you shouldn't do it, mind you - definitely try it out (preferably both ways) and see which works better, and then compare with what it would look like just keeping things separate (eg. your code has a refernce to the form map, and a reference to the template model, and it just uses each when it needs them).<br> <br> I'm rambiling now because the more I think about it the more I see alternate avenues to explore. So I'll shut up before I futher confuse things...<br> <br> Does this help at all?<br> <br> Christian<br> <br> <br> <blockquote cite="[email protected]" type="cite"><br> So I have to re-implement both FormMap and TemplateModel in my class... I choosed to extend from FormMap as it seems to me is does quite a lot of things, so what I have to is implement TemplateModel, that is TemplateModel itself, Model and Contextual. <br> <br> None of these interfaces specifies a fireModelChanged method. But all implementations have it ! <br> <br> So my question is finally : should I implement it also ? If so, why isn't it part of Model interface ? <br> <br> Thanks a lot, <br> <br> Franck <br> <br> <br> Le 16 sept. 05, à 22:54, Christian Cryder a écrit : <br> <br> <blockquote> If you are implementing by extending from one of the abstract implementations, then you won't need to. If you are implementing from scratch, then should look at the abstract implementations for guidance. <br> <br> Typically, all the end programmer needs to do is the former, not the latter. But I don't know exactly what you are doing so I can't say for sure... <br> <br> That help? If you are still unsure, send some more info and I will try and answer it better for your specific needs. <br> <br> Christian <br> <br> Franck Routier wrote:So, if I'm implementing Model interface, should I add such a method (cut and paste from say DefaultTemplateModel), although it is not really part of the interface contract ? <br> <blockquote><br> <br> Le 16 sept. 05, à 15:40, Christian Cryder a écrit : <br> <br> <blockquote><br> <br> fireModelChanged is an internal method - you should never need to invoke it. Basically, it is defined in the various model implementations - when you change data to the model (eg. adding data, removing data, etc), then the model notifies any listeners "hey, something has happened - better refresh yourselves" <br> <br> So this method is an internal communication mechanism for models to talk to the components that use them. <br> <br> THat help? <br> <br> Christian <br> <br> Franck Routier wrote:Hi Barracudans, <br> <blockquote><br> I was just wondering if / where fireModelChanged is defined ? <br> Is it defined in an interface ? <br> <br> I which to implement TemplateModel, which means also implementing Model and Contextual, but I cannot see fireModelChanged anywhere. However, all AbstractxxxModel I see are providing a fireModelChanged() method. <br> <br> I was just wondering what this is for, and why it's not defined in the interfaces if mandatory. <br> <br> Thanks, <br> <br> Franck <br> <br> <br> <br> <tt> --</tt> <br> <tt> Barracuda mailing list</tt> <br> <tt><!-- 0000,0000,EEEE --><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> </tt> <br> <tt><!-- 0000,0000,EEEE --><a class="moz-txt-link-freetext" href="http://www.objectweb.org/wws/lists/projects/barracuda">http://www.objectweb.org/wws/lists/projects/barracuda</a> </tt><br> <br> </blockquote> <br> <br> -- <br> Christian Cryder <br> Internet Architect, ATMReports.com <br> <br> <i>"Coffee? I could quit anytime, just not today"</i> <br> <i><!-- 0000,0000,EEEE --><font size="-1"><a class="moz-txt-link-freetext" href="http://seelifedifferently.blogspot.com">http://seelifedifferently.blogspot.com</a></font></i> <br> <br> <br> -- <br> <br> Barracuda mailing list <br> <br> <!-- 0000,0000,EEEE --><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <br> <br> <!-- 0000,0000,EEEE --><a class="moz-txt-link-freetext" href="http://www.objectweb.org/wws/lists/projects/barracuda">http://www.objectweb.org/wws/lists/projects/barracuda</a> <br> <br> </blockquote> <tt><br> <br> -- <br> Barracuda mailing list <br> <!-- 0000,0000,EEEE --><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <br> <!-- 0000,0000,EEEE --><a class="moz-txt-link-freetext" href="http://www.objectweb.org/wws/lists/projects/barracuda">http://www.objectweb.org/wws/lists/projects/barracuda</a> <br> </tt><br> </blockquote> <br> <br> -- <br> <!-- Arial -->Christian Cryder <br> <!-- Arial --> Internet Architect, <!-- 0000,0000,EEEE -->ATMReports.com <br> <br> <i>"Coffee? I could quit anytime, just not today"</i> <br> <i><!-- 0000,0000,EEEE --><font size="-1"><a class="moz-txt-link-freetext" href="http://seelifedifferently.blogspot.com">http://seelifedifferently.blogspot.com</a></font></i> <br> <br> <br> -- <br> <br> Barracuda mailing list <br> <br> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <br> <br> <a class="moz-txt-link-freetext" href="http://www.objectweb.org/wws/lists/projects/barracuda">http://www.objectweb.org/wws/lists/projects/barracuda</a> <br> <br> </blockquote> <pre wrap=""> <hr size="4" width="90%"> -- Barracuda mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="http://www.objectweb.org/wws/lists/projects/barracuda">http://www.objectweb.org/wws/lists/projects/barracuda</a> </pre> </blockquote> <br> <br> <div class="moz-signature">-- <br> <meta http-equiv="Content-Language" content="en-us"> <meta http-equiv="Content-Type" content="text/html; "> <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <title>Foo bar rama</title> <table border="0"> <tbody> <tr> <td width="100%"> <hr align="left" size="1" width="350"> </td> </tr> <tr> <td width="100%"><font face="Arial">Christian Cryder<br> Internet Architect, <a href="http://atmreports.com">ATMReports.com</a></font></td> </tr> <tr> <td width="100%"> <hr align="left" size="1" width="350"> </td> </tr> <tr> <td width="100%"> <p align="center"><i>"Coffee? I could quit anytime, just not today"<br> <a href="http://seelifedifferently.blogspot.com"><font size="2">http://seelifedifferently.blogspot.com</font></a></i></p> </td> </tr> </tbody> </table> </div> </body> </html> --------------050406040409040801060907-- ------------=_1126969131-5037-23 Content-Type: text/plain; name="message-footer.txt" Content-Disposition: inline; filename="message-footer.txt" Content-Transfer-Encoding: 8bit -- Barracuda mailing list [email protected] http://www.objectweb.org/wws/lists/projects/barracuda ------------=_1126969131-5037-23--