[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795689#comment-13795689
]
Lenny Primak commented on TAP5-2196:
For AMD, if module paths are the same, and they are used twice, that is
actually supported by requireJS,
and will be handled correctly.
Also, as you said, JQueryUI being loaded prior to JQuery wouldn't happen in
this case.
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795640#comment-13795640 ] Lance commented on TAP5-2099: - More discussion here: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Read-only-bindings-How-do-I-set-their-value-from-a-mixin-td5720446i20.html > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6 >Reporter: Lance > Labels: binding, literal-binding, mixin, symbol-binding > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795618#comment-13795618
]
Barry Books commented on TAP5-1611:
---
You are correct. I would be nice if that was fixed. I'm going to go vote on it.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795569#comment-13795569
]
Lance commented on TAP5-1611:
-
I think you're hitting this
https://issues.apache.org/jira/browse/TAP5-2099
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795544#comment-13795544
]
Magnus Kvalheim edited comment on TAP5-2196 at 10/15/13 8:01 PM:
-
Yes, that's right.
It's typically modules with dependencies of their own which one can configure
through paths.
The approach you've taken with specifying a script path as module dependency
have afaik some potential problems.
First - the loading order of dependencies is not guaranteed so jqueryui may be
loaded before jquery. (think it's unlikely for jquery case though).
Not recommended way for AMD modules, also what happens if several require same
script?
The proper way, I believe, is to make shim config for non AMD scripts, and
paths for AMD ones(can reference other domain). Would make it more portable as
well.. I'm no expert on the area - just what I've picked up so far.
Problem is that shim and path config currently in tapestry is limited which
leave us with few options...
was (Author: mag...@kvalheim.dk):
Yes, that's right.
It's typically modules with dependencies of their own which one can configure
through paths.
The approach you've taken with specifying a script path as module dependency
have afaik some potential problems.
First - the loading of dependencies is not guaranteed so jqueryui may be loaded
before jquery. (think it's unlikely for jquery case though).
Not recommended way for AMD modules, also what happens if several require same
script?
The proper way, I believe, is to make shim config for non AMD scripts, and
paths for AMD ones(can reference other domain). Would make it more portable as
well.. I'm no expert on the area - just what I've picked up so far.
Problem is that shim and path config currently in tapestry is limited which
leave us with few options...
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This messag
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795544#comment-13795544
]
Magnus Kvalheim commented on TAP5-2196:
---
Yes, that's right.
It's typically modules with dependencies of their own which one can configure
through paths.
The approach you've taken with specifying a script path as module dependency
have afaik some potential problems.
First - the loading of dependencies is not guaranteed so jqueryui may be loaded
before jquery. (think it's unlikely for jquery case though).
Not recommended way for AMD modules, also what happens if several require same
script?
The proper way, I believe, is to make shim config for non AMD scripts, and
paths for AMD ones(can reference other domain). Would make it more portable as
well.. I'm no expert on the area - just what I've picked up so far.
Problem is that shim and path config currently in tapestry is limited which
leave us with few options...
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795545#comment-13795545
]
Barry Books commented on TAP5-1611:
---
I'll take a look at that. My problem is I tried to @Bind a mixin parameter to
the textfield translate parameter but when I try and set it from the mixin it's
read only. Perhaps I can use the DefaultProvider to make a default that's not
read only.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
[ https://issues.apache.org/jira/browse/TAP5-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship updated TAP5-2203: --- Labels: client javascript (was: ) > Popup Calendar used by DateField does not have an option to cancel changes > -- > > Key: TAP5-2203 > URL: https://issues.apache.org/jira/browse/TAP5-2203 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Paul Stanton >Assignee: Robert Zeigler > Labels: client, javascript > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
[ https://issues.apache.org/jira/browse/TAP5-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship reassigned TAP5-2203: -- Assignee: (was: Robert Zeigler) > Popup Calendar used by DateField does not have an option to cancel changes > -- > > Key: TAP5-2203 > URL: https://issues.apache.org/jira/browse/TAP5-2203 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Paul Stanton > Labels: client, javascript > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
[ https://issues.apache.org/jira/browse/TAP5-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship updated TAP5-2203: --- Affects Version/s: (was: 5.2.4) > Popup Calendar used by DateField does not have an option to cancel changes > -- > > Key: TAP5-2203 > URL: https://issues.apache.org/jira/browse/TAP5-2203 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Paul Stanton >Assignee: Robert Zeigler > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
[ https://issues.apache.org/jira/browse/TAP5-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship updated TAP5-2203: --- Component/s: tapestry-core > Popup Calendar used by DateField does not have an option to cancel changes > -- > > Key: TAP5-2203 > URL: https://issues.apache.org/jira/browse/TAP5-2203 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Paul Stanton >Assignee: Robert Zeigler > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
Howard M. Lewis Ship created TAP5-2203: -- Summary: Popup Calendar used by DateField does not have an option to cancel changes Key: TAP5-2203 URL: https://issues.apache.org/jira/browse/TAP5-2203 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton Assignee: Robert Zeigler Fix For: 5.3 using the datefield component, if a user changes their mind there seems to be no way for them to close the popup without changing the value in some way. once the icon has been clicked, there's no option to close the popup explicitly and selecting the current value is disabled so the user has to select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2203) Popup Calendar used by DateField does not have an option to cancel changes
[ https://issues.apache.org/jira/browse/TAP5-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship updated TAP5-2203: --- Affects Version/s: 5.4 Fix Version/s: (was: 5.3) > Popup Calendar used by DateField does not have an option to cancel changes > -- > > Key: TAP5-2203 > URL: https://issues.apache.org/jira/browse/TAP5-2203 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Paul Stanton >Assignee: Robert Zeigler > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795501#comment-13795501
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
You don't need to override TextField to set a different default translator.
Just override, advise or decorate the ComponentDefaultProvider service.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795436#comment-13795436
]
Barry Books commented on TAP5-1611:
---
I do think it's easy to fix just declare the components in the tml file.
If the types don't match (such as datafield) I'm not sure overriding the block
would help. I think you would get a class cast exception when using any of the
blocks in the page.
Personally I'd like to override TextField because it sets a default translator
that can't be overridden with a mixin.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795377#comment-13795377
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
Barry, we can change the out-of-the-box property edition blocks so they use
AbstractField or Field instead of TextField, TextArea et al. From a first look,
it doesn't seem that change would cause any problems. If they do, like it may
be the case for DateField. Anyway, you can override the edition block for any
type without much effort. Anyway x2, besides DateField, I don't see this kind
of case happening often.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795363#comment-13795363
]
Barry Books commented on TAP5-1611:
---
My concern is if you override anything used by propertyEditBlocks
https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=blob;f=tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyEditBlocks.java;h=9ab91e920d5dd5188f651e3ccb4c5a441c3cd24d;hb=HEAD
you will break the entire page and no beanEditForms will work. I would suggest
fixing the Edit/Display blocks pages so they work if the component is
overridden. This would also server and an example for how to do things going
forward
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795344#comment-13795344
]
Lenny Primak commented on TAP5-2196:
Never mind... you probably have paths relative to your own web site,
so you don't know the exact path ahead of time
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795329#comment-13795329
]
Lenny Primak commented on TAP5-2196:
Why do you need paths for AMD modules?
Its nice to have but not a requirement.
You can just define the dependency directly like this: (example)
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/resources/META-INF/modules/flowlogix/HighlightEffect.js?name=tapestry-5.4
jquery-ui is non AMD (but it works)
and should work for AMD modules even better
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795324#comment-13795324
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
Barry, I'm also very against the idea of a fallback. I hate silent failures,
and that would be one.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795323#comment-13795323
]
Thiago H. de Paula Figueiredo edited comment on TAP5-1611 at 10/15/13 3:48 PM:
---
I think Barry's suggested additional checks would be quite difficult and
time-consuming to implement, if even feasible. Regarding @InjectContainer and
@InjectComponent, this kind of error can already happen in Tapestry right now,
without component substitution, so I think no additional checks are needed.
Anyway, the ideal is to have the field as generic (to the top of the
class/interface hierarchy) as possible, as in pure, non-Tapestry OOP best
practices, avoiding concrete classes and favoring interfaces when possible
(Field instead of TextField, etc).
I agree with Lance's suggestion that the contribution to the service should be
a logical name, not the page/component/mixin class, as the service
(ComponentClassResolver) methods will need to advise take a logical name as a
parameter : resolvePageNameToClassName(String),
resolveComponentTypeToClassName(String), resolveMixinTypeToClassName(String).
was (Author: thiagohp):
I think Barry's suggested additional checks would be quite difficult and
time-consuming to implement, if even feasible. Regarding @InjectContainer and
@InjectComponent, this kind of error can already happen in Tapestry right now,
without component substitution, so I think no added checks are needed. Anyway,
the ideal is to have the field as generic (to the top of the class/interface
hierarchy) as possible, as in pure, non-Tapestry OOP best practices, avoiding
concrete classes and favoring interfaces when possible (Field instead of
TextField, etc).
I agree with Lance's suggestion that the contribution to the service should be
a logical name, not the page/component/mixin class, as the service
(ComponentClassResolver) methods will need to advise take a logical name as a
parameter : resolvePageNameToClassName(String),
resolveComponentTypeToClassName(String), resolveMixinTypeToClassName(String).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795323#comment-13795323
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
I think Barry's suggested additional checks would be quite difficult and
time-consuming to implement, if even feasible. Regarding @InjectContainer and
@InjectComponent, this kind of error can already happen in Tapestry right now,
without component substitution, so I think no added checks are needed. Anyway,
the ideal is to have the field as generic (to the top of the class/interface
hierarchy) as possible, as in pure, non-Tapestry OOP best practices, avoiding
concrete classes and favoring interfaces when possible (Field instead of
TextField, etc).
I agree with Lance's suggestion that the contribution to the service should be
a logical name, not the page/component/mixin class, as the service
(ComponentClassResolver) methods will need to advise take a logical name as a
parameter : resolvePageNameToClassName(String),
resolveComponentTypeToClassName(String), resolveMixinTypeToClassName(String).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795278#comment-13795278
]
Lance edited comment on TAP5-1611 at 10/15/13 3:23 PM:
---
I'm happy with a (meaningful) exception at runtime. I dislike the idea of it
falling back to the non-overridden component. As I said, in some cases the only
fix available is to extend the component you want to override.
was (Author: uklance):
I'm happy with a (meaningful) exception at runtime. As I said, in some cases
the only fix available is to extend the component you want to override.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795278#comment-13795278
]
Lance edited comment on TAP5-1611 at 10/15/13 3:22 PM:
---
I'm happy with a (meaningful) exception at runtime. As I said, in some cases
the only fix available is to extend the component you want to override.
was (Author: uklance):
I would assume an exception would occur at runtime when Tapestry tries to push
a round peg (the override) into a square hole (the code referencing the old /
overridden component).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795278#comment-13795278
]
Lance edited comment on TAP5-1611 at 10/15/13 3:13 PM:
---
I would assume an exception would occur at runtime when Tapestry tries to push
a round peg (the override) into a square hole (the code referencing the old /
overridden component).
was (Author: uklance):
I would assume an exception would occur at runtime when Tapestry tries to push
a round peg (the override) into a square hole (the code referencing the old
type).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795278#comment-13795278
]
Lance commented on TAP5-1611:
-
I would assume an exception would occur at runtime when Tapestry tries to push
a round peg (the override) into a square hole (the code referencing the old
type).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795260#comment-13795260
]
Barry Books commented on TAP5-1611:
---
I agree about starting fresh and the Datepicker I wrote does exactly that. The
question is what happens if you try and override a component that does not have
a common interface. I think in the case above it cannot cause the page to break
because there is no simple way to fix it. It could just continue to use the
existing Tapestry Component.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795251#comment-13795251
]
Magnus Kvalheim commented on TAP5-2196:
---
Have been updating our javascript libs recently and looks like requirejs seems
is getting some traction. A lot of jquery plugins bake AMD in.
Today I looking into updating Masonry
http://masonry.desandro.com/appendix.html#requirejs
And imagesloaded
https://github.com/desandro/imagesloaded
Both which ask to configure path's.
Currently I've disabled amd for these scripts (Find replace define.amd to
define.amd && false). It's either that or modifying the scrips and it's deps
(and dependencies of those) to my structure.
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795190#comment-13795190
]
Lance edited comment on TAP5-1611 at 10/15/13 1:48 PM:
---
I'm agreeing with you that there are certain cases where the override MUST
extend the component it is overriding. And that tapestry will blow up in these
cases where it tries to push a round peg in a square hole (hopefully with a
nice error message).
But there are many cases where it is perfectly valid for a component override
to be a totally different implementation. As long as it has the same parameters
(and maybe a common interface). There will be times when you want to override a
component with private fields that can't be accessed. In these cases, it would
be nice to "start afresh" instead of being forced to inherit from the component
being overridden.
was (Author: uklance):
I'm agreeing with you that there are certain cases where the override MUST
extend the component it is overriding. And that tapestry will blow up in these
cases where it tries to push a round peg in a square hole (hopefully with a
nice error message).
But there are many cases where it is perfectly valid for a component override
to be a totally different component. As long as it has the same parameters (and
maybe a common interface). There will be times when you want to override a
component with private fields that can't be accessed. In these cases, it would
be nice to "start afresh" instead of being forced to inherit from the component
being overridden.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795190#comment-13795190
]
Lance commented on TAP5-1611:
-
I'm agreeing with you that there are certain cases where the override MUST
extend the component it is overriding. And that tapestry will blow up in these
cases where it tries to push a round peg in a square hole (hopefully with a
nice error message).
But there are many cases where it is perfectly valid for a component override
to be a totally different component. As long as it has the same parameters (and
maybe a common interface). There will be times when you want to override a
component with private fields that can't be accessed. In these cases, it would
be nice to "start afresh" instead of being forced to inherit from the component
being overridden.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file
[ https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795168#comment-13795168 ] Magnus Kvalheim commented on TAP5-2201: --- So have tried to disable and have tapestry the lifting. Actually still see exact same issues for example in the mentioned bootstrap css files. Both provide an asset.gz version, but on one the font urls are /asset and the other it's /asset.gz. (except for the .woff file) Think this don't cause issues in most cases, but if it was reversed and it's somehow giving compressed versions to clients that don't support it I suppose there would be. Have not found this case yet though.. Still I wonder why it's giving different results internally for a /asset.gz/ version file? Here are some live urls as well http://www.movellas.com/asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css http://www.movellas.com/asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css > Serious issue with assets and checksums - different for same file > - > > Key: TAP5-2201 > URL: https://issues.apache.org/jira/browse/TAP5-2201 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Magnus Kvalheim > Labels: 5.4.22 > Attachments: bootstrap.server2.css, bootstrap.server3.css, > server2.png, server3.png > > > Hi everybody. > Today we've launched a website based on 5.4. We're very exited about the > upcoming release(5.4) and I'll post separately about our experiences (mostly > great). > Post release we've identified a potential serious issue related to assets and > their checksums. > What we see is that a handful of the assets generate different hashes for the > same file. > =Example: bootstrap.css= > Server 1: > /asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css > Server 2: > /asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css > Server 3: > /asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css > Server 3 - restart: > /asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css > We also see the same behaviour for the non gzip version of bootstrap.css. > It is not only for /meta/ > =JCarouselWrapper.css= > /asset/app/f59da774/mixins/ui/JCarouselWrapper.css > /asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css > As you can see - we're load balanced with app served from several nodes. > Normally I'd serve these through CloudFront on a cookieless domain (with > tapestry as origin), but it's not possible as load balanced assets could hit > 'wrong' server and get the 404 instead. > So for now they are served through website domain with sticky sessions - and > pray that it don't cause us problems... :) > All are served with same web container: > Apache Tomcat/7.0.39 > JDK 1.7.0_11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795079#comment-13795079
]
Barry Books commented on TAP5-1611:
---
I don't think failure is an option in this case. Typically a module has one
AppPropertyEditBlock page. If one of the blocks is invalid the whole page will
not compile and you would have to provide an override for every block in the
page.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795074#comment-13795074
]
Lance commented on TAP5-1611:
-
Yes, this would fail if the override does not extend the component. But
tapestry could fail with a nice error message saying why it's invalid. I don't
see this as a reason to force inheritance for all component overrides.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795061#comment-13795061
]
Barry Books commented on TAP5-1611:
---
True (and I think the documentation should reflect that) but you can also do
this
@MixinClasses(value=JQueryDatePicker.class)
@Component(parameters =
{ "value=context.propertyValue", "label=prop:context.label",
"translate=prop:dateTranslator",
"validate=prop:dateValidator",
"clientId=prop:context.propertyId",
"annotationProvider=context" })
private TextField dateField;
which is common in propertyEditBlocks
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795053#comment-13795053
]
Lance edited comment on TAP5-1611 at 10/15/13 10:46 AM:
Yes, this was the sort of ClassCastException I was referring to. But if you
instead declared:
{code}
@InjectComponent
private FormValidationControl form;
{code}
You could use interfaces to defensively future proof your code for component
overrides.
was (Author: uklance):
Yes, this was the sort of ClassCastException I was referring to. But if you
instead declared:
{code}
@InjectComponent
private FormValidationControl form;
{code}
You could use interfaces to defensively code against component overrides.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795053#comment-13795053
]
Lance commented on TAP5-1611:
-
Yes, this was the sort of ClassCastException I was referring to. But if you
instead declared:
{code}
@InjectComponent
private FormValidationControl form;
{code}
You could use interfaces to defensively code against component overrides.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.png (61 kB image/png) - Updated render phase chart (PNG) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.gliffy (39 kB application/octet-stream) - Updated render phase chart (Gliffy source) Stop watching space | Change email notification preferences View Attachments
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795049#comment-13795049
]
Barry Books commented on TAP5-1611:
---
It does seem like you might need to extend the components/mixins to make this
work.
@InjectComponent
private Form form;
is pretty common
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794976#comment-13794976
]
Lance edited comment on TAP5-1611 at 10/15/13 8:09 AM:
---
I'm not sure it's legal to be referencing component classes in your AppModule
since component classes are loaded by the component classloader. It's probably
better to reference class names instead to avoid cluttering permgen
unnecessarily (I could be wrong here). I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same parameters /
interfaces). This would obviously cause ClassCastException in a mixin which
declares a concrete component type for @InjectContainer.
was (Author: uklance):
I'm not sure it's legal to be referencing component classes in your AppModule
since component classes are loaded by the component classloader. It's probably
better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same parameters /
interfaces). This would obviously cause ClassCastException in a mixin which
declares a concrete component type for @InjectContainer.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794976#comment-13794976
]
Lance edited comment on TAP5-1611 at 10/15/13 8:08 AM:
---
I'm not sure it's legal to be referencing component classes in your AppModule
since component classes are loaded by the component classloader. It's probably
better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same parameters /
interfaces). This would obviously cause ClassCastException in a mixin which
declares a concrete component type for @InjectContainer.
was (Author: uklance):
I'm not sure it's legal to be referencing component classes in your AppModule
since component classes are loaded by the component classloader. It's probably
better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same properties /
interfaces).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794976#comment-13794976
]
Lance edited comment on TAP5-1611 at 10/15/13 8:02 AM:
---
I'm not sure it's legal to be referencing component classes in your AppModule
since component classes are loaded by the component classloader. It's probably
better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same properties /
interfaces).
was (Author: uklance):
I'm not sure it's legal to be referencing component class files in your
AppModule since component classes are loaded by the component classloader. It's
probably better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same properties /
interfaces).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794976#comment-13794976
]
Lance commented on TAP5-1611:
-
I'm not sure it's legal to be referencing component class files in your
AppModule since component classes are loaded by the component classloader. It's
probably better to reference class names instead to avoid cluttering permgen
unnecessarily. I think the config would be similar to:
{code}
public static void contributeComponentOverrides(MappedConfiguration config) {
config.add("grid", "com.basepackage.components.MyGrid");
}
{code}
I'm also wondering if the override actually needs to extend the component it is
overriding. It might be sufficient for it to be compatible (same properties /
interfaces).
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
