On 11/17/05, Christian Meder <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-11-17 at 16:29 -0500, Laurie Harper wrote:
> > Christian Meder wrote:
> > > On Thu, 2005-11-17 at 03:40 +0000, [EMAIL PROTECTED] wrote:
> > >>
> > >> /**
> > >>+ * <p>The CGLIB <code>Enhancer</code> which we will use to
> dynamically
> > >>+ * add getters/setters if 'enhanced' is true in the form config.
> > >>+ */
> > >>+ protected transient Enhancer enhancer = null;
> > >
> > > Shouldn't we mark enhancer private as getBeanEnhancer will always do
> the
> > > right thing ?
> >
> > protected seems to be the norm in Struts code for members of classes
> > likely to be subclassed. This is just consistent with other members in
> > the class.
>
> Just after posting I saw that it's consistent with other members in the
> class ;-)
>
> But that still leaves the point that the re-introspection after
> deserialization isn't properly encapsulated and bug-prone if you can
> access the enhancer directly without the check. Consistently the same
> issue for the other transient members like beanClass ;-)
>
> >
> > >>+
> > >>+ /**
> > >> * <p>The form bean configuration information for this class.</p>
> > >> */
> > >> protected FormBeanConfig config = null;
> > >>@@ -193,9 +192,14 @@
> > >> public DynaBean newInstance()
> > >> throws IllegalAccessException, InstantiationException {
> > >>
> > >>- FormPropertyConfig[] props = config.findFormPropertyConfigs();
> > >>- DynaActionForm dynaBean = (DynaActionForm) doCreate(props);
> > >>+ DynaActionForm dynaBean = null;
> > >>+ if (config.isEnhanced()) {
> > >>+ dynaBean = (DynaActionForm) getBeanEnhancer().create();
> > >>+ } else {
> > >>+ dynaBean = (DynaActionForm) getBeanClass().newInstance();
> > >>+ }
> > >> dynaBean.setDynaActionFormClass(this);
> > >>+ FormPropertyConfig[] props = config.findFormPropertyConfigs();
> > >> for (int i = 0; i < props.length; i++) {
> > >> dynaBean.set(props[i].getName(), props[i].initial());
> > >> }
> > >>@@ -273,6 +277,24 @@
> > >>
> > >>
> > >> /**
> > >>+ * <p>Return the <code>Enhancer</code> we are using to construct new
> > >>+ * instances, re-introspecting our [EMAIL PROTECTED] FormBeanConfig} if
> necessary
> > >>+ * (that is, after being deserialized, since <code>enhancer</code> is
> > >>+ * marked transient).</p>
> > >>+ *
> > >>+ * @return The enhancer used to construct new instances.
> > >>+ */
> > >>+ protected Enhancer getBeanEnhancer() {
> > >>+
> > >>+ if (enhancer == null) {
> > >>+ introspect(config);
> > >>+ }
> > >>+ return (enhancer);
> > >
> > > Idiom question. Why the brackets around enhancer ?
> >
> > Local coding convention... They're redundant but, again, this is
> > consistent with other code.
>
> Thanks. But is there any explanation for this coding convention ?Some people like it, some people don't. There is no standard in the Struts coding guidelines for whether to use this or not, so you'll find a mixture, probably depending on who wrote the code. With almost 5,000 Checkstyle warnings, not including this kind of thing, I think this is the least of our problems. ;-) And at one point, the Struts code base had zero Checkstyle errors. Sad. -- Martin Cooper Greetings, > > > Christian > -- > Christian Meder, email: [EMAIL PROTECTED] > > The Way-Seeking Mind of a tenzo is actualized > by rolling up your sleeves. > > (Eihei Dogen Zenji) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
