> This extend > child thing really didn't seem to be intuitive at all. > However, once I completely removed it things became more clear. > > 1) It has no id tag.. So w/o asking or rtfm you're not going to know > what's going on > 2) Wouldn't naming the hierarchy parent > child be more logical? In > english.. extend + child have no relation...
I suppose it's a philosophical question on a number of levels. The first level is whether inheritance is a parent/child relationship - I mean no offence to anyone reading this but, clearly, inheritance is not a parent/child relationship. To confuse parent/child with superclass/subclass (or base class/derived class in the more accurate but old fashion terminology) is a mistake. Subclasses are not children of their superclass. If I have a Vehicle class and extend that to make MotorCycle and Automobile classes then these subclasses are not 'children' of the vehicle class. They 'extend' vehicle but they are not 'owned by it' or 'born from it'. Parent/child is not an inheritance relationship - it's an association relationship. Anyone who uses the world 'child' in an inheritance context probably skipped the first lecture of their OO 1.0.1 course and stayed at the bar. So let's pretend to ignore that word 'child' is used in this way in wicket and move to the next philosophical issue: Is the extent/child tag 'the' inheritance relationship or is it just the mechanism that allows us to take advantage of inheritance in the markup domain (for the first time in any framework I've seen - which is why I like wicket so much) and allows a derived class' markup to provide markup to fill a gap specified in the base class' markup. I believe that in wicket the 'extend/child' tag is the latter. It's really just like a virtual method in a class definition. You're declaring some aspect within the base class for which no implementation is provided in that base class but which must be provided in some class that extends that base class. We do this all the time in OO - and we are allowed to provide multiple instances of these in any class, not just one instance per class, and we therefore give each instance a different name. The implementation is provided in a subclass by a method that has a matching name. This is how true and more powerful markup inheritance could work in wicket. Naming would only be necessary in situations where more than one markup chuck needs to be 'overridden' or provided in a subclass. Sure some of this could be done by creating extra Panel components but sometimes I just have some markup that is common to only a portion of my hierarchy. It seems fudgy to have to create new Panel components to achieve what can be achieved at a markup level quite quickly and easily and with less code and less classes. > 3) Instead of relying on the idea of child tags.. Just add more panels > or other components that fit your need. You have to break out of the OO > mindset a bit, but there's a lot of potential once you think outside the > bun. I've aborted the adoption of all other Java UI frameworks I've ever found because they forced me to break out of the OO mindset. I came to wicket, and I'm guessing many other OOers have also because it, more than any other UI framework, let's me keep my OO mindset that has been the source of all my successes and the production of robust, high quality, maintainable solutions for my clients over the last 15 years. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
