[jira] Closed: (WICKET-3273) Redo Componet's internal data and ModelImpl methods

["Jeremy Thomerson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Thomerson closed WICKET-3273.
------------------------------------

    Resolution: Won't Fix

I also don't agree with the proposed changes (and am glad that Richard acknowledged that we wouldn't in his initial submission).  Reasons: same as Igor's.

Additionally, find it odd that you did this to avoid casting, and in your example, you don't use generics for the model, and you cast there :)

> Redo Componet's internal data and ModelImpl methods
> ---------------------------------------------------
>
>                 Key: WICKET-3273
>                 URL: https://issues.apache.org/jira/browse/WICKET-3273
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.5-M3
>         Environment: all
>            Reporter: Richard Emberson
>            Priority: Minor
>         Attachments: TestRun.java
>
>
> I am in the process of adding type parameters to Component and
> those derived classes are not parameterize so that I can
> get strong typing when accessing a Componet's Model. To do this
> a different mechanism is needed for storing the Model object
> in the Component.
> The current "data" storage mechanism is very well optimized for
> low memory usage. The problem is that one can not use it and still
> have typed Models without casting.
> In addition, the data_* methods are not easy to understand
> nor can their data-structure algorithms be tested without
> exercising other methods (like not being able to test an
> ArrayList directly but having to all access mediated by other
> methods).
> So, for my project I've devised a data structure that allows for
> separate testing and Model strong typing (without having to
> use instanceof and casts). Access to the underlying data is
> also faster.
> I also believe that separating out the data structure is a
> good thing; IMHO, Component is rather plump.
> An attached file contains the IHolder class and implementations.
> Using the IHodler classes, the data instance variable, data_* methods
> and ModelImpl access methods become (this is the
> non-type-parameterized version):
>   // why is this not private in Wicket?
>   private IHolder data = EmptyHolder.instance;
>   private final int data_length() {
>     return data.length();
>   }
>   private final Object data_get(int index) {
>     return data.get(index);
>   }
>   private final Object data_set(int index, Object object) {
>     data.set(index, obj);
>   }
>   private final void data_add(Object object) {
>     data = data.append(obj);
>   }
>   private final void data_insert(int position, Object object) {
>     data = data.insert(position, obj);
>   }
>   private final Object data_remove(int position){
>     data = data.remove(position);
>   }
>   final IModel<?> getModelImpl() {
>     return data.getModel();
>   }
>   final void setModelImpl(IModel<?> model) {
>     data = data.setModel(model);
>   }
> Also, the use of the FLAG_MODEL_SET can be removed throughout
> the rest of Component.
> I actually do not expect the Wicket team to adapt my changes here
> since for Components with data there is an extra reference and
> with Models, yet another reference; which is to say, greater
> memory usage. But, I want strong typing, so this is what I've done.
> Oh, yes, all of the test pass (after adjusting the
> org.apache.wicket.markup.html.debug.WicketComponentTreeTest test).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.