[
https://issues.apache.org/jira/browse/WICKET-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6597.
-------------------------------------
Resolution: Won't Do
No one shared an opinion on this but I think it should grow as a third party
library first and eventually moved to wicket-core if it proves itself.
> Automatic Component/FormComponents based on java.lang.reflect.Field.type,
> extensible also to links and buttons
> --------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-6597
> URL: https://issues.apache.org/jira/browse/WICKET-6597
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Reporter: Martin Terra
> Priority: Minor
>
> We propose that Wicket would have the capability to instantiate type-specific
> FormComponents (CheckBox, DropDownChoice, etc.) automatically in a somewhat
> similar way that it now automatically handles type conversions (components
> such as Labels, Links, and Buttons to be generated also with suitable
> parametrization). It automatically also generates markup based on a template
> (input, select, link, button, label, etc. have somewhat different markup and
> there can be a custom standard structure like prefixes and suffixes etc.).
> There would be a default out-of-the-box mapping which user can override as
> necessary. The components are instantiated in a way that gives the components
> access to the context in which they are in, for example a model instantiator
> can access other components in the same context or an ajax event can access
> other components as necessary.
>
> We have madea a custom implementation for this in our project using a
> component factory (we can maybe post here later as it gets more refined,
> whichever comes first). The benefits of this approach is that we can make a
> "defined-once-used-many-times" definition of an api (validation rules,
> component interdependencies, authorization) by listing properties user is
> allowed to interact with in a static manner, and using the same definition to
> generate both wicket ui and rest api. For example. Furthermore, it encourages
> best practices html/css layout generation when all components are generated
> in a standard way (for example, each FormComponent is automatically
> accompanied by a Label). We can make a static definition for a View and its
> contents could be Sections which contain Tables, Labels or FormComponents
> that are defined in a generic "table of contents" which is used to generate
> the ui. The "table of contents" can also be used for search based on either
> data values or field label (or even tooltip) properties.
>
> Something similar (but maybe not as generic) has been discussed way back in
> thread
> [http://apache-wicket.1842946.n4.nabble.com/Component-Factory-and-code-against-interface-td1846370.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
