You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Willis Blackburn (JIRA)" <ji...@apache.org> on 2008/10/08 12:25:53 UTC

[jira] Reopened: (WICKET-1862) Please consider backing out changes to Component that merged dissimilar objects into an Object[]

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

Willis Blackburn reopened WICKET-1862:
--------------------------------------


If it has to be this way, then I think that there could be a better implementation.  Regardless of memory considerations, the code that manipulates the object array seems quite complex for what it does.  How about an interface IComponentExtras that declares several methods:

    IModel getModel()
    MetaData[] getMetaData()
    IBehavior[] getBehaviors()

There could two implementations, one that just has a model, and one that all three fields.  Component has a reference to an instance of the interface, which can be null.

The interface also has methods to add a Model, Behavior, etc. that return a reference to the interface.  If the current implementation doesn't have a field for whatever is being added, then it transforms itself into an implementation that does.

    IComponentExtras addModel(IModel model)
    IComponentExtras addMetaData ...

This strategy would be easier to understand and better-typed, and could be extended to support other infrequently-used "extras."  You could even provide a way to use a single IComponentExtras instance across multiple components (SharedComponentExtras or whatever), offering potentially greater memory savings.



> Please consider backing out changes to Component that merged dissimilar objects into an Object[]
> ------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1862
>                 URL: https://issues.apache.org/jira/browse/WICKET-1862
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.3.4
>            Reporter: Willis Blackburn
>            Priority: Minor
>
> In Wicket 1.2, the members of the Component class were pretty straightforward.
> But in 1.3, three fields, including the model, have been merged into a single Object[], and there are new methods called data_get, data_set, data_length, data_add, data_remove, and data_insert, to deal with the array.
> I cannot determine from the source code why this was done, but it does not seem like a change for the better.  The Component class is now very confusing, and the change has also made working with any Component subclass (in other words, practically every Wicket class!) in the debugger more difficult.  I think that when three fields that used to be accessed in a simple and straightforward manner are replaced by 160 lines of code, there needs to be some very compelling reason.
> Maybe the motivation was to reduce the memory footprint of a Component instance that does not have any model, behaviors, or metadata, or maybe one that just has one of the three?  If so, is that really so compelling?  Is the memory footprint that large?  Are users suffering from problems that have been addressed by this solution?  In the context of the memory usage of a typical webapp, saving something like 8 bytes per Component instance does not seem like that much.

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