Jon:
> I don't get how .set. would work?
> What is .set.?
.set is a instance of an inner class:
public class MyClass
{
public Set set = new Set();
final public class Set
{
public MyClass background(String color)
{
/* do stuff */
return MyClass.this;
}
}
}
The .set.*() methods act mostly in
the same way as .set*() methods.
So:
Body Body.set.background(String)
will perform the same function as:
Body Body.setBackground(String)
The difference is that the .set.*()
methods belong to an inner class,
rather than the class itself. The
advantage here is that the inner
class is an entirely separate class
that conveniently sets up a link
to its outer class. The design
enables the outer class and all
its subclasses to do method chaining
with the correct return type.
So whereas we cannot have:
class SubBody extends Body;
SubBody SubBody.setBackground(String)
because it conflicts with:
Body SubBody.setBackground(String)
we can have:
class SubBody extends Body;
SubBody SubBody.set.background(String)
How does this improve ECS?
Take a look at this method found in
the ElementAttributes class
Element Element.setID(String id)
It must return type Element for all
subclasses.
This means the following won't work:
new Button()
.setID("Submit")
.setName("Submit")
.setType("submit")
.setValue("Submit this form");
Because from setID onwards, you have
an object of type Element, not Button.
The fix for above using the current ECS
could be to use setID last.
ie:
new Input()
.setName("Submit")
.setType("submit")
.setValue("Submit this form")
.setID("submit");
But that is an inconsistent solution.
Furthermore, the following won't work
no matter what order you put it in
because both setID and setClass returns
Element - not Input nor ElementAttribute:
new Input()
.setName("Submit")
.setType("submit")
.setValue("Submit this form")
.setID("submit")
.setClass("CoolButton");
You could try the messy option of type
casting which gets worse the more methods
you try to chain:
((Input)new Input()
.setName("Submit")
.setType("submit")
.setValue("Submit this form")
.setID("submit"))
.setClass("CoolButton");
Or the cleaner solution of using temporary
variables:
Temp input = new Button();
input
.setName("Submit")
.setType("submit")
.setValue("Submit this form")
.setID("submit");
input
.setClass("CoolButton");
In these cases, we have more or less
compromised the benefits of method
chaining.
Using the inner class methods you can
method chain all the way in whatever
order you like since all these methods
can be made to return class Input:
new Input()
.set.id("submit")
.set.class_("CoolButton")
.set.name("Submit")
.set.type("submit")
.set.value("Submit this form");
The inner class methods themselves do
not support polymorphism because of the
same reason - they do not belong to the
same class. That problem can be fixed
by retaining the original methods and
having the inner class methods call
these implementations.
For example, we keep:
Body Body.setBackground()
and let it be called by the new method:
SubBody SubBody.set.background()
Here, if you subclass Body to SubBody, you
can override Body.setBackground() to take
advantage of polymorphism, and use
SubBody.set.background() for method chaining.
The current ECS can't claim to be consistent
and I am not in a position to claim the change
will save typing. (each line contains an
extra "." operator) It is my opinion that the
changes improve consistency and extensibility
at a small cost.
There are several costs involved:
A larger ECS
An extra "." operator
Instantiation of inner classes
But it appears to me that many previous design
decisions in ECS tend to tolerate these small
overheads in order to improve consistency and
extensibility: filters, tagmodifiers, cases,
class heirarchy and the like.
I would argue that the proposed changes work
in the same spirit.
Hope the explanation helps.
I will try to make some code and examples
available as soon as possible.
______
John
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
