[
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.
