[
https://issues.apache.org/jira/browse/WICKET-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641199#comment-16641199
]
Martin Terra edited comment on WICKET-6597 at 10/7/18 8:07 PM:
---------------------------------------------------------------
Thanks. Did have a look at that, but seems bit thick. What we are proposing is
very lightweight, implementation looks more like:
{{ *editorForm.add(new
DataFieldPropertiesListViewPanel<>("group-of-input-elements", viewContext,*}}
*{{groupOfDataFieldPropertiesWithLabelsList, targetModel));}}*
Without any xml or annotation soup (at least for now).
was (Author: mmakundi):
Thanks. Did have a look at that, but seems bit thick. What we are proposing is
very lightweight, implementation looks more like:
{{}} *{{editorForm.add(new
DataFieldPropertiesListViewPanel<>("group-of-input-elements", viewContext,}}*
*{{groupOfDataFieldPropertiesWithLabelsList, targetModel));}}*
Without any xml or annotation soup (at least for now).
> 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)
