> > 1) constructors are atomic > > Wicket components have always been thread-unsafe by design, so I fail > to see how this is relevant. Do you plan on sharing Wicket components > across threads anytime soon? Just define Component.isInit() and set it > to true if a component has been initialized, and prevent > double-initialization.
Atomic != threadsafe. See http://en.wikipedia.org/wiki/Atomicity. Either a component's construction completes including the parents it is added, or not. One of the side effects of the add method is that the hierarchical position of the component is postponed until it is added to a parent, and even then the action is not complete, as those components might still need to be added to their parents. > > 2) an exception thrown from a constructor will prevent the object from > > being created (security) > > Correct me if I'm wrong (you probably know more about this issue than > me) but isn't the real security concern whether or not the Component may > be rendered as opposed to whether or not it may be constructed? For > example, normal users do not have admin access, so they should not be > able to visit admin-only WebPages. You could enforce this security check > at render time. It's just the concept of fail early. It is generally a good idea in programming to fail as early as possible if you know you are going to fail. Objects might be expensive to create etc. > > 3) constructor parameters are much easier to pass. if you have a > > parameter that you want to pass from a constructor you would have to > > store it as a field so it is available in init(), this makes things > > really really dirty and break encapsulation. > > I think that is subjective. All JavaBeans work this way (if you need > to > use a variable later on, you are forced to store it as a field) but this > has never bothered me. I already do this kind of thing with Wicket when > I need a variable at render time (this happens quite often). In my view, > this is no more ugly. If you want to tighten things up and force users of your class to provide it's dependencies at construction time, requiring constructor arguments is a robust technique. This is not a new concept, and even has been one of the main battle arguments in the constructor vs property dependency IoC camp. We don't have to join that discussion though, as we are not building a managed IoC framework. > > 4) constructors insure the proper order of creation. you cant have > > things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) <== error > > because p1 hasnt been initted and bound to the page yet. > > The situation you describe exists with the current implementation > (i.e. > this is nothing new). IMHO this is common sense. I don't think anyone > would find it confusing. I made mistakes with it. Why wouldn't anyone else? Furthermore, lots of times you don't own the whole component creation code, giving rise to more uncertainties. > > 5) constructors, as the name implies, are used for constructing things > > in java. > > Right, but we're not constructing, we're binding. A WebPage floating > in > space is just fine. You should be able to use a constructor to create > such an instance. Using Swing as an example (since Wicket is based upon > it), you often create a component using a constructor and bind it using > add() or setParent(). As we want component creation and setting of parents to be atomic, we are not merely binding. A component floating into space has problems, particalarly if you depend on its place in the hierarchy in the constructor. This is not just theory. People are having troubles with this, especially when it comes to ajax/ javascript integration and component interaction. > This discussion is regarding whether or not we should be passing the > parent into the constructor as opposed to the current add() mechanism. I > would argue that the current discussion is quite relevant in that we are > trying to give our feedback on this proposal. I'm not arguing against > the existence of constructors just for the sake of argument. No 'we' (the committers) decided on using the constructor pattern and were asking you about your opinion as to when this should be implement. Or actually, whether this change should be made together with the move to JDK 5. Here is what Martijn asked: <quote> The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? </quote> Eelco ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
