Thomas Menke wrote:
> For the record I answer my own question:
>
> Thomas Menke wrote:
>
>> Problem is: I need to instantiate customer based on the information in
>> customerType. But before I can read customerType I can't instantiate the
>> correct class because I don't know which type. And after the
>> customerType has been set by stripes it is already too late because
>> stripes already tried and failed to set the customer.name property.
>>
First of all - Thank You for sharing your solution!!! :-)
That's an interesting problem. So you would like your customerType
setter method - as a side effect (if I can call it that) - to create the
appropriate customer subclass and you want to have a pre-specified
ordering on the execution of the setter methods of the action bean for
everything to work. Interesting... .
I commented on this primarily because I have a similar need and had to
think about how I would go about solving it.
>> What would be the "best" way to deal with this?
>>
Not sure if this is a written best practice no-no or not but relying on
a setter to produce the appropriate class before other setter methods
get called is not the "best" way to deal with this class of problem in
my personal opinion... . An alternative idea is presented later (below).
> Stripes populates the values in order of the length of the name of the
> property. Thus I just need to make sure that this:
> public Customer.Type customerType;
> is shorter than that:
> public Customer customer;
>
Wow. Okay. So that sounds like your design is relying on a "very"
specific coding / implementation in the Stripes framework.
Question: Does this specific Stripes "implementation" equally apply to
Stripes 1.6?
Question: Can this specific Stripes "implementation" be guaranteed to
ALWAYS work this way and never be refactored in the future?
Question: Can you always guarantee a newer variable will not be
introduced that is shorter than this variable "cType"?
Question: If your code is ever maintained by some one else can you
guarantee that some one doesn't come along and say... "cType" is a
poorly named variable... let me expand that to "customerType"... oops
that just broke your action bean... sure you could plaster comment
warnings all over the place but guess what this happens...
I'm not sure anyone could say "yes" to the above answers even if you
could say "yes" to the 1st it is the 2nd that I would concern myself
with the most.
I know you say you wanted to write test code to learn Stripes so the
4rth question above is probably not even worth mentioning but you did
ask how "best" to solve this :-)
> It is not right now, thus I rename customerType to cType. Then I use a
> setter-method for cType which is guaranteed to be called prior to
> setting any nested values of customer by stripes. In this method I
> instantiate the correct sub class of Customer and assign it to customer.
> And everything works fine.
>
> Special thanks to bgunter&aporter for explaing that to me :-).
>
It's great that Ben and Aaron assisted in helping you resolve this
offline and as such I am not sure what caveats and disclaimers they
attached to your following this approach (which I imagine there were
some or plenty)... . Though personally I think framework Developers
should discourage their user community from relying on such specific
implementation details of the framework especially when it depends on
something as fluid as length of a variable name.
Why? Because there are alternative solutions that although not as
direct that are more robust and should be prefered. For example:
One important realization is that as far as the action bean is concerned
the type it sees from the JSP is of the abstract superclass when setting
any attributes or calling methods. The only time it deals with the
specific subclass is in the setter of of the customer type. Well how about:
1) Creating a simple helper object that extends Customer called say
CustomerDetails except you also add to it:
a) a CustomerType attribute
b) a method with the following signature that simply examines the
customer type attribute that it has internally, constructs the
appropriate subclass and populates it with the attributes it has internally:
public Customer createCustomer()
2) (Optional) Make the CustomerDetails class package private and put it
in the same package as its action ean
3) Having Stripes deal with and populate this CustomerDetails object
which is an attribute retained by the action bean
4) In your event handler methods methods simply do to get the
appropriate customer object to perform further processing e.g. data
access, service call, etc...:
Customer customer = this.getCustomerDetails.createCustomer();
What is the downside:
- Well you are instantiating an additional intermediary object i.e. you
are not dealing directly with the end object
What is the upside:
- It eliminates having code that has a side effect in a setter which
goes against best practices (for me personally)
- It is agnostic of how Stripes is implemented internally "today" and
"tomorrow" (barring major revision framework changes of course)
- It eliminates having to incorporate disclaimer / banner comments on
NOT changing cType and not making ANY other variable shorter than this
cType variable
- It does not sacrifice readability of the variable (as per your choice
to use cType)
- The code that determines the type and creates the appropriate subclass
is encapsulated in the helper object
In the end, everyone can decide what makes sense for them but IFF anyone
chooses to adopt the strategy you propose as a solution then I would
strongly encourage above and beyond banner comments et al. having at
least 1 Unit Test case that specifically tests for and ensures that the
"side effect" is not broken in the future.
HTH,
--Nikolaos
> Thomas
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Nikolaos Giannopoulos
Director, BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
