tag:blogger.com,1999:blog-7110614371420404415.post9191956914903447163..comments2023-05-10T23:34:14.549-06:00Comments on Discussions and Tutorials on Software Development: Trinidad versus Tomahawk component architectureAnonymoushttp://www.blogger.com/profile/12230997086550680222noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-7110614371420404415.post-21448618924727668172007-09-17T09:56:00.000-06:002007-09-17T09:56:00.000-06:00Hello Andrew,I agree FacesBean represents a break ...Hello Andrew,<br><br>I agree FacesBean represents a break on encapsulation to some level since you an alter the attribute value without calling the accessors. However, there's at least 2 major advantages with FacesBean architecture:<br><br>1. Reduction of boilerplate code since FacesBean automatically deals with value expressions, state saving, etc.<br><br>2. Far more efficient than getAttributes() map is you make loosely coupled renderers since PropertyKey is more or less a dynamic enum granting an access speed comparable to arrays. However, if the renderer is strongly coupled to the component class, you'll get a small performance cost with FacesBean. However, Trinidad often delegate rendering of some component parts to other renderers and strongly coupling the renderers to the component class would prevent that.<br><br>Note: The contract of getAttributes() is still enforced, calling a get on the map will call the getter in the component that will in turn call the FacesBean to get the current value. This is, on the other hand, very inefficient, but Trinidad does not use attribute map in many places.<br><br>About maven-faces-plugin, you don't have to use FacesBean architecture with it. MyFaces 1.2.x use it to generate its components.<br><br><br>Regards,<br><br>~ SimonAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7110614371420404415.post-64649773932397533832007-09-17T10:17:00.000-06:002007-09-17T10:17:00.000-06:00Simon's already listed most of the advantages of t...Simon's already listed most of the advantages of the FacesBean approach, which is why we went that way. Performance was foremost on our minds. The ability to decouple rendering from a specific component was second highest priority. Elimination of boilerplate was third highest.<br><br>Also, to emphasize peformance more: the approach of making the bean accessors "do the work" has painful implications for state saving performance. Every attribute is stored, whether or not it's been set. FacesBean is much more efficient with sparsely-set components (the most common case by far).<br><br>As a historical footnote, the FacesBean approach also made it possible to bootstrap the old UIX codebase (see the UINode code, etc.) into JSF land without a true violation of encapsulation.<br><br>I don't understand why you see FacesBean as a massive violation of OO principles - in particular, for FacesBean-based components, the FacesBean <b>is</b> the contract, and the accessors are mere convenience functions. As long as you think the accessors are the contract, yes, you'd think it's violating encapsulation.<br><br>BTW, the term encapsulation is entirely dependent on your scope. If you insist that the scope is the UIComponent instance, then it's violating encapsulation in this artifical sense. But that's your arbitrary choice. The encapsulation is perfectly fine on the combination of the FacesBean and the UIComponent, which are a united pair, and there's nothing wrong in OO with such a strategy!<br><br>So, yes, it's different. But I'm completely happy with the choices we've made, and think Trinidad has a very coherent, considered architecture.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7110614371420404415.post-62565918576385681322007-09-17T11:47:00.000-06:002007-09-17T11:47:00.000-06:00"The reason FacesBean violates OOD is that it dele..."The reason FacesBean violates OOD is that it delegates the behavior of the UIComponent to the FacesBean".<br><br>No. Delegation is perfectly acceptable OOD. At most, it's breaking JavaBean concepts, but JavaBeans != OO.<br><br>"With this model, the component's properties are reduced to the security and functionality of public fields."<br><br>That's false. FacesBean is in no practical way worse than the getter/setter design seen in 99.9% of JSF components - if we're going to talk OO hardcore, the entire JavaBean approach is a lousy OO approach. As an aside, FacesBeans today don't do much validation of their input - it'd be easy and worthwhile to add more validation - though for example, they make it trivial to note that an attribute doesn't support EL, and block attempts to do so, which I suspect most component developers forget.<br><br>It's also entirely OK for a component to store state that is entirely private off the FacesBean. But if you're exposing a public getter + setter, give up the notion that you've got some super private implementation detail.<br><br>"Is the efficiency of FacesBean worth the cost of bypassing encapsulation and reducing a component's methods to not much more than a Map? JDK 1.5 has made reflection much faster, and if the Method references were cached, it would be a much smaller performance hit. "<br><br>YES. The efficiency is TOTALLY worth it. I don't know how much time you've spent profiling JSF applications and other similar frameworks, but I've spent tons. The time spent looking in component attribute maps is HUGE. Reflection is only a fraction of that - it is very easy for HashMap.get() to become a dominant part of overhead, and the optimizations in FacesBean to make PropertyKeys faster to retrieve (especially around the indices) are major wins.<br><br>"With the FacesBean, the component now is permanently bound to the data that it serializes, as people now code against the PropertyKey names instead of the exposed properties."<br><br>As opposed to getAttributes().get()???<br><br>"Also, the way that an object chooses to serialize its data (saveState, restoreState behaviors in JSF), is an internal, not external function."<br><br>That's ridiculous. Everyone <i>hates</i> writing that boilerplate code for this internal function, and it's inefficient splitting this implementation among the class hierarchy, layering arrays in arrays in arrays. The FacesBean approach to state saving is far better.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7110614371420404415.post-28061484014127438932007-09-17T11:51:00.000-06:002007-09-17T11:51:00.000-06:00Andrew,Data alteration control is still possible w...Andrew,<br><br>Data alteration control is still possible with FacesBean by using an internal FacesBean decorator to override getProperty and setProperty methods. You then decorate the FacesBean returned by getFacesBean with it and you'll be able to do whatever you want with incoming requests.<br><br>That pattern makes it even easier to add, for example, a logging behavior as you can enable it for all properties in a single method. <br><br>As for validations, you can enforce whatever you want in the decorator using a Map<PropertyKey, Method> to not hit the performance. I agree it's not as intuitive as getter/setter, but it works.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7110614371420404415.post-23215335010989118012007-09-18T03:46:00.000-06:002007-09-18T03:46:00.000-06:00You might be interested in the CDK that comes with...You might be interested in the CDK that comes with RichFaces - keeps the standard UIComponent. It does require its own project though.<br><br>A bit short on docs atm, but some are being worked on.Anonymousnoreply@blogger.com