You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by simon <sk...@apache.org> on 2008/05/31 21:48:26 UTC
core, myfaces-builder-plugin: issues noticed
Hi,
Here are some things I noticed when reviewing the tlddocs for
core11-based-on-myfaces-builder.
Tag f:selectItems now has a "rendered" attribute, which it should not.
Tag f:view has id, rendered and binding which it should not.
Tag h:inputTextarea previously had "datafld", "datasrc", "dataformatas".
These are no longer there, but they do not exist in the sun docs either.
Tags h:message/h:messages previously had "dir", "lang" attributes, and a
set of "onmouse*", "onkey*" attributes. These are no longer there, but
they do not exist in the sun docs either.
I'll try to look into these myself if I can find time. But if anyone
wants to deal with them first, please do!
Regards,
Simon
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Jun 4, 2008 at 3:49 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> A practical use case for converter inheritance would be identical --
> allowing custom converter per-instance messages properties.
>
> Since the JSF spec does not declare validator and converter classes
> final, assume that inheritance is possible and that properties will
> propagate. Again, if you are subclassing a converter, there's
> obviously some reason why you did it rather than writing one from
> scratch.
Ok, no prob, I'll do it on converters too.
regards
Leonardo Uribe
>
>
> On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
> >
> >
> >
> > On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger <mk...@gmail.com>
> > wrote:
> > >
> > > On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
> > > > * @JSFJspProperty name = "message" inheritedTag="true" returnType =
> > > > "java.lang.String" longDesc = "alternate validation error message
> format
> > > > string"
> > > > */
> > > > public class CSVValidator extends ValidatorBase
> > > >
> > > > Inheritance of properties for converters and validators are not
> > supported
> > > > (in my concept there is no sense to allow this, but if there is a
> strong
> > > > reason we can study the impact and change it), so all properties
> defined
> > on
> > > > the parent (in that case ValidatorBase) should be defined again with
> > > > inheritedTag="true".
> > >
> > > I guess I'd have to disagree that there's no sense in allowing
> > > inheritance of properties on validators and converters. The original
> > > goal of the ValidatorBase class was to provide a message properties to
> > > all subclasses.
> > >
> > > Why would you extend a validator or converter if you weren't planning
> > > on using the same properties of the parent?
> >
> > ValidatorBase is the only case of inheritance for validators. But from
> this
> > point of view is valid allow inheritance for validators. Checking the
> code,
> > a change only affects tomahawk, so there is no problem. On sandbox, all
> > validators do not use detailMessage and summaryMessage on its tld (this
> fact
> > makes me feel strange about ValidatorBase), so this could be a side
> effect.
> > I'll try it in deep and commit it. I'm not found yet a practical usage
> for
> > inheritance for converters, so I'll let it as is
> >
> > Thanks for your suggestions
> >
> > Leonardo Uribe
> >
> >
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by Mike Kienenberger <mk...@gmail.com>.
A practical use case for converter inheritance would be identical --
allowing custom converter per-instance messages properties.
Since the JSF spec does not declare validator and converter classes
final, assume that inheritance is possible and that properties will
propagate. Again, if you are subclassing a converter, there's
obviously some reason why you did it rather than writing one from
scratch.
On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
>
> On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger <mk...@gmail.com>
> wrote:
> >
> > On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
> > > * @JSFJspProperty name = "message" inheritedTag="true" returnType =
> > > "java.lang.String" longDesc = "alternate validation error message format
> > > string"
> > > */
> > > public class CSVValidator extends ValidatorBase
> > >
> > > Inheritance of properties for converters and validators are not
> supported
> > > (in my concept there is no sense to allow this, but if there is a strong
> > > reason we can study the impact and change it), so all properties defined
> on
> > > the parent (in that case ValidatorBase) should be defined again with
> > > inheritedTag="true".
> >
> > I guess I'd have to disagree that there's no sense in allowing
> > inheritance of properties on validators and converters. The original
> > goal of the ValidatorBase class was to provide a message properties to
> > all subclasses.
> >
> > Why would you extend a validator or converter if you weren't planning
> > on using the same properties of the parent?
>
> ValidatorBase is the only case of inheritance for validators. But from this
> point of view is valid allow inheritance for validators. Checking the code,
> a change only affects tomahawk, so there is no problem. On sandbox, all
> validators do not use detailMessage and summaryMessage on its tld (this fact
> makes me feel strange about ValidatorBase), so this could be a side effect.
> I'll try it in deep and commit it. I'm not found yet a practical usage for
> inheritance for converters, so I'll let it as is
>
> Thanks for your suggestions
>
> Leonardo Uribe
>
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
> > * @JSFJspProperty name = "message" inheritedTag="true" returnType =
> > "java.lang.String" longDesc = "alternate validation error message format
> > string"
> > */
> > public class CSVValidator extends ValidatorBase
> >
> > Inheritance of properties for converters and validators are not supported
> > (in my concept there is no sense to allow this, but if there is a strong
> > reason we can study the impact and change it), so all properties defined
> on
> > the parent (in that case ValidatorBase) should be defined again with
> > inheritedTag="true".
>
> I guess I'd have to disagree that there's no sense in allowing
> inheritance of properties on validators and converters. The original
> goal of the ValidatorBase class was to provide a message properties to
> all subclasses.
>
> Why would you extend a validator or converter if you weren't planning
> on using the same properties of the parent?
ValidatorBase is the only case of inheritance for validators. But from this
point of view is valid allow inheritance for validators. Checking the code,
a change only affects tomahawk, so there is no problem. On sandbox, all
validators do not use detailMessage and summaryMessage on its tld (this fact
makes me feel strange about ValidatorBase), so this could be a side effect.
I'll try it in deep and commit it. I'm not found yet a practical usage for
inheritance for converters, so I'll let it as is
Thanks for your suggestions
Leonardo Uribe
Re: core, myfaces-builder-plugin: issues noticed
Posted by Mike Kienenberger <mk...@gmail.com>.
On 6/4/08, Leonardo Uribe <lu...@gmail.com> wrote:
> * @JSFJspProperty name = "message" inheritedTag="true" returnType =
> "java.lang.String" longDesc = "alternate validation error message format
> string"
> */
> public class CSVValidator extends ValidatorBase
>
> Inheritance of properties for converters and validators are not supported
> (in my concept there is no sense to allow this, but if there is a strong
> reason we can study the impact and change it), so all properties defined on
> the parent (in that case ValidatorBase) should be defined again with
> inheritedTag="true".
I guess I'd have to disagree that there's no sense in allowing
inheritance of properties on validators and converters. The original
goal of the ValidatorBase class was to provide a message properties to
all subclasses.
Why would you extend a validator or converter if you weren't planning
on using the same properties of the parent?
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Jun 4, 2008 at 2:18 PM, simon <si...@chello.at> wrote:
>
> On Mon, 2008-06-02 at 21:57 -0500, Leonardo Uribe wrote:
> > Hi
> >
> > I have committed the changes.
>
> Thanks!
>
> >
> > Reading the email again, I forget to mention my opinion about change
> > "tagExcluded" setting to "ignore".
> >
> > In the plugin there are several levels of "ignore" (only two used in
> > practice):
> >
> > tagExcluded = true: generate the property with state saving and
> > restoring code on the .tld if applies, but do not generate on the Tag
> > class and do not include on the tld. It is also used to exclude
> > from .tld already defined properties.
> >
> > inheritedTag = true: assume that the code on Tag is inside the
> > hierarchy, and include on the tld.
> >
> > transient(never used)=generate property but do not included on
> > saveState and restoreState methods.
> >
> > I feel that "tagExcluded" or a similar name is more intuitive than
> > "ignore", according to the intention of the property.
>
> Ah..but I think the isRendered method should be overridden too.
>
> You said in an earlier email:
> <quote>
> override isRendered is bad, because this method is used on processXXX
> and encodeXXX methods
> </quote>
>
> I presume you meant that overriding it to throw an exception would not
> work. I agree, but would override it like this:
>
> public boolean isRendered() {
> return true;
> }
>
> After all, if nobody is allowed to set the rendered state, then that is
> what will happen anyway, right?
>
Ok, I agree with you, so I'll add this code and commit it.
>
> And this makes it clear that there is no point in trying to save the
> rendered flag in saveState/restoreState etc. But it's not really
> "transient" state either; it's state that never should have existed.
> Which is why I think "ignore" would be a better name. But that's not so
> important.
>
> Sorry, but I didn't follow your description of "inheritedTag". What do
> you mean by "inside the hierarchy"?
>
"inheritedTag" is a variable of PropertyMeta used to check if a property has
already defined on a parent tag class. For example, UIComponentTag define
id, binding and rendered; HtmlCommandButtonTag extends from UIComponentTag,
but all properties on UICommand and HtmlCommandButton are not defined on
UIComponentTag, so this properties has " inheritedTag = "false" " but the
properties of UIComponent has " inheritedTag = "true" ".
The practical example where you use "inheritedTag" on a custom component (on
@JSFProperty or @JSFJspProperty) is when you want to insert a custom tag
class on the hierarchy (see
org.apache.myfaces.custom.suggestajax.AbstractSuggestAjaxTag). In this case
we define a new tagSuperclass. The definition of the component looks like
this:
/**
* @JSFComponent
* configExcluded = "true"
* class = "org.apache.myfaces.custom.suggestajax.SuggestAjax"
* superClass =
"org.apache.myfaces.custom.suggestajax.AbstractSuggestAjax"
* tagClass = "org.apache.myfaces.custom.suggestajax.SuggestAjaxTag"
* tagSuperclass =
"org.apache.myfaces.custom.suggestajax.AbstractSuggestAjaxTag"
*/
public abstract class AbstractSuggestAjax extends HtmlInputText
implements AjaxComponent, LocationAware
But on AbstractSuggestAjaxTag there is defined suggestedItemsMethod and
maxSuggestedItems, because it has a very specific code. inheritedTag is used
to tell the builder plugin that do not generate code on
org.apache.myfaces.custom.suggestajax.SuggestAjaxTag related to this
properties.
Other example when I use "inheritedTag" is this:
/*
* @JSFValidator
* name = "s:validateCSV"
* tagClass = "org.apache.myfaces.custom.csvvalidator.ValidateCSVTag"
* tagSuperclass = "org.apache.myfaces.validator.ValidatorBaseTag"
* serialuidtag = "-8874279182242196266L"
*
* @JSFJspProperty name = "message" inheritedTag="true" returnType =
"java.lang.String" longDesc = "alternate validation error message format
string"
*/
public class CSVValidator extends ValidatorBase
Inheritance of properties for converters and validators are not supported
(in my concept there is no sense to allow this, but if there is a strong
reason we can study the impact and change it), so all properties defined on
the parent (in that case ValidatorBase) should be defined again with
inheritedTag="true".
>
> Regards,
> Simon
>
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by simon <si...@chello.at>.
On Mon, 2008-06-02 at 21:57 -0500, Leonardo Uribe wrote:
> Hi
>
> I have committed the changes.
Thanks!
>
> Reading the email again, I forget to mention my opinion about change
> "tagExcluded" setting to "ignore".
>
> In the plugin there are several levels of "ignore" (only two used in
> practice):
>
> tagExcluded = true: generate the property with state saving and
> restoring code on the .tld if applies, but do not generate on the Tag
> class and do not include on the tld. It is also used to exclude
> from .tld already defined properties.
>
> inheritedTag = true: assume that the code on Tag is inside the
> hierarchy, and include on the tld.
>
> transient(never used)=generate property but do not included on
> saveState and restoreState methods.
>
> I feel that "tagExcluded" or a similar name is more intuitive than
> "ignore", according to the intention of the property.
Ah..but I think the isRendered method should be overridden too.
You said in an earlier email:
<quote>
override isRendered is bad, because this method is used on processXXX
and encodeXXX methods
</quote>
I presume you meant that overriding it to throw an exception would not
work. I agree, but would override it like this:
public boolean isRendered() {
return true;
}
After all, if nobody is allowed to set the rendered state, then that is
what will happen anyway, right?
And this makes it clear that there is no point in trying to save the
rendered flag in saveState/restoreState etc. But it's not really
"transient" state either; it's state that never should have existed.
Which is why I think "ignore" would be a better name. But that's not so
important.
Sorry, but I didn't follow your description of "inheritedTag". What do
you mean by "inside the hierarchy"?
Regards,
Simon
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have committed the changes.
Reading the email again, I forget to mention my opinion about change
"tagExcluded" setting to "ignore".
In the plugin there are several levels of "ignore" (only two used in
practice):
tagExcluded = true: generate the property with state saving and restoring
code on the .tld if applies, but do not generate on the Tag class and do not
include on the tld. It is also used to exclude from .tld already defined
properties.
inheritedTag = true: assume that the code on Tag is inside the hierarchy,
and include on the tld.
transient(never used)=generate property but do not included on saveState and
restoreState methods.
I feel that "tagExcluded" or a similar name is more intuitive than "ignore",
according to the intention of the property.
regards
Leonardo Uribe
On Mon, Jun 2, 2008 at 7:29 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> I have checked if there is some related code and doing this:
>
> /**
> * Disable this property; although this class extends a base-class that
> * defines a read/write rendered property, this particular subclass
> * does not support setting it. Yes, this is broken OO design: direct
> * all complaints to the JSF spec group.
> *
> * JSFProperty tagExcluded="true"
> */
> public void setRendered(boolean state) {
> throw new UnsupportedOperationException();
> }
>
> works without problem (override isRendered is bad, because this method is
> used on processXXX and encodeXXX methods).
>
> I'll commit those changes tomorrow (Today is holiday in Colombia).
>
> regards
>
> Leonardo Uribe
>
> On Sun, Jun 1, 2008 at 4:29 AM, simon <si...@chello.at> wrote:
>
>>
>> On Sat, 2008-05-31 at 16:45 -0500, Leonardo Uribe wrote:
>> > Hi
>> >
>> > On Sat, May 31, 2008 at 2:48 PM, simon <sk...@apache.org> wrote:
>> > Hi,
>> >
>> > Here are some things I noticed when reviewing the tlddocs for
>> > core11-based-on-myfaces-builder.
>> >
>> > Tag f:selectItems now has a "rendered" attribute, which it
>> > should not.
>> >
>> > This problem is caused because the plugin enforces inheritance of
>> > properties. The solution is do something like this:
>> >
>> > * @JSFComponent
>> > * name = "f:selectItems"
>> > * bodyContent = "empty"
>> > * tagClass = "org.apache.myfaces.taglib.core.SelectItemsTag"
>> > * desc = "UISelectItems"
>> > * @JSFJspProperty name = "rendered" returnType = "boolean"
>> > tagExcluded = "true"
>> > */
>> > public class UISelectItems extends UIComponentBase
>> >
>> > When the hierarchy is merged, tagExcluded = "true" takes precedence,
>> > so this property is not mentioned on tld anymore.
>>
>> I actually think the problem is that the OO inheritance hierarchy in the
>> JSF spec is wrong. If UISelectItems does not support the "rendered"
>> property, then it should not subclass something that does. This breaks
>> the principle of substitutability, which is one of the fundamental
>> concepts of OO programming:
>> http://en.wikipedia.org/wiki/Substitutability
>>
>> This does appear to be a problem in the spec, not in our code. However I
>> don't agree with the solution of just excluding the property from the
>> tag; that fixes only part of the issue by blocking JSP tags from
>> accessing the property, but nothing else.
>>
>> I would instead suggest something like this in the
>> UISelectItem/UISelectItems classes:
>>
>> /**
>> * Disable this property; although this class extends a base-class that
>> * defines a read/write rendered property, this particular subclass
>> * does not support setting it. Yes, this is broken OO design: direct
>> * all complaints to the JSF spec group.
>> *
>> * JSFProperty tagExcluded="true"
>> */
>> public void setRendered(boolean state) {
>> throw new UnsupportedOperationException();
>> }
>>
>> Actually, I would suggest renaming tagExcluded to "ignore". This is not
>> a jsp-tag-specific issue; any view templating language including
>> facelets, clay, and whatever else gets invented, should act as if this
>> method is *not* a JSFProperty even though the inherited settings say it
>> is.
>>
>>
>> What do you think?
>>
>> Regards,
>> Simon
>> >
>>
>>
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have checked if there is some related code and doing this:
/**
* Disable this property; although this class extends a base-class that
* defines a read/write rendered property, this particular subclass
* does not support setting it. Yes, this is broken OO design: direct
* all complaints to the JSF spec group.
*
* JSFProperty tagExcluded="true"
*/
public void setRendered(boolean state) {
throw new UnsupportedOperationException();
}
works without problem (override isRendered is bad, because this method is
used on processXXX and encodeXXX methods).
I'll commit those changes tomorrow (Today is holiday in Colombia).
regards
Leonardo Uribe
On Sun, Jun 1, 2008 at 4:29 AM, simon <si...@chello.at> wrote:
>
> On Sat, 2008-05-31 at 16:45 -0500, Leonardo Uribe wrote:
> > Hi
> >
> > On Sat, May 31, 2008 at 2:48 PM, simon <sk...@apache.org> wrote:
> > Hi,
> >
> > Here are some things I noticed when reviewing the tlddocs for
> > core11-based-on-myfaces-builder.
> >
> > Tag f:selectItems now has a "rendered" attribute, which it
> > should not.
> >
> > This problem is caused because the plugin enforces inheritance of
> > properties. The solution is do something like this:
> >
> > * @JSFComponent
> > * name = "f:selectItems"
> > * bodyContent = "empty"
> > * tagClass = "org.apache.myfaces.taglib.core.SelectItemsTag"
> > * desc = "UISelectItems"
> > * @JSFJspProperty name = "rendered" returnType = "boolean"
> > tagExcluded = "true"
> > */
> > public class UISelectItems extends UIComponentBase
> >
> > When the hierarchy is merged, tagExcluded = "true" takes precedence,
> > so this property is not mentioned on tld anymore.
>
> I actually think the problem is that the OO inheritance hierarchy in the
> JSF spec is wrong. If UISelectItems does not support the "rendered"
> property, then it should not subclass something that does. This breaks
> the principle of substitutability, which is one of the fundamental
> concepts of OO programming:
> http://en.wikipedia.org/wiki/Substitutability
>
> This does appear to be a problem in the spec, not in our code. However I
> don't agree with the solution of just excluding the property from the
> tag; that fixes only part of the issue by blocking JSP tags from
> accessing the property, but nothing else.
>
> I would instead suggest something like this in the
> UISelectItem/UISelectItems classes:
>
> /**
> * Disable this property; although this class extends a base-class that
> * defines a read/write rendered property, this particular subclass
> * does not support setting it. Yes, this is broken OO design: direct
> * all complaints to the JSF spec group.
> *
> * JSFProperty tagExcluded="true"
> */
> public void setRendered(boolean state) {
> throw new UnsupportedOperationException();
> }
>
> Actually, I would suggest renaming tagExcluded to "ignore". This is not
> a jsp-tag-specific issue; any view templating language including
> facelets, clay, and whatever else gets invented, should act as if this
> method is *not* a JSFProperty even though the inherited settings say it
> is.
>
>
> What do you think?
>
> Regards,
> Simon
> >
>
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by simon <si...@chello.at>.
On Sat, 2008-05-31 at 16:45 -0500, Leonardo Uribe wrote:
> Hi
>
> On Sat, May 31, 2008 at 2:48 PM, simon <sk...@apache.org> wrote:
> Hi,
>
> Here are some things I noticed when reviewing the tlddocs for
> core11-based-on-myfaces-builder.
>
> Tag f:selectItems now has a "rendered" attribute, which it
> should not.
>
> This problem is caused because the plugin enforces inheritance of
> properties. The solution is do something like this:
>
> * @JSFComponent
> * name = "f:selectItems"
> * bodyContent = "empty"
> * tagClass = "org.apache.myfaces.taglib.core.SelectItemsTag"
> * desc = "UISelectItems"
> * @JSFJspProperty name = "rendered" returnType = "boolean"
> tagExcluded = "true"
> */
> public class UISelectItems extends UIComponentBase
>
> When the hierarchy is merged, tagExcluded = "true" takes precedence,
> so this property is not mentioned on tld anymore.
I actually think the problem is that the OO inheritance hierarchy in the
JSF spec is wrong. If UISelectItems does not support the "rendered"
property, then it should not subclass something that does. This breaks
the principle of substitutability, which is one of the fundamental
concepts of OO programming:
http://en.wikipedia.org/wiki/Substitutability
This does appear to be a problem in the spec, not in our code. However I
don't agree with the solution of just excluding the property from the
tag; that fixes only part of the issue by blocking JSP tags from
accessing the property, but nothing else.
I would instead suggest something like this in the
UISelectItem/UISelectItems classes:
/**
* Disable this property; although this class extends a base-class that
* defines a read/write rendered property, this particular subclass
* does not support setting it. Yes, this is broken OO design: direct
* all complaints to the JSF spec group.
*
* JSFProperty tagExcluded="true"
*/
public void setRendered(boolean state) {
throw new UnsupportedOperationException();
}
Actually, I would suggest renaming tagExcluded to "ignore". This is not
a jsp-tag-specific issue; any view templating language including
facelets, clay, and whatever else gets invented, should act as if this
method is *not* a JSFProperty even though the inherited settings say it
is.
What do you think?
Regards,
Simon
>
Re: core, myfaces-builder-plugin: issues noticed
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
On Sat, May 31, 2008 at 2:48 PM, simon <sk...@apache.org> wrote:
> Hi,
>
> Here are some things I noticed when reviewing the tlddocs for
> core11-based-on-myfaces-builder.
>
> Tag f:selectItems now has a "rendered" attribute, which it should not.
This problem is caused because the plugin enforces inheritance of
properties. The solution is do something like this:
* @JSFComponent
* name = "f:selectItems"
* bodyContent = "empty"
* tagClass = "org.apache.myfaces.taglib.core.SelectItemsTag"
* desc = "UISelectItems"
* @JSFJspProperty name = "rendered" returnType = "boolean" tagExcluded =
"true"
*/
public class UISelectItems extends UIComponentBase
When the hierarchy is merged, tagExcluded = "true" takes precedence, so this
property is not mentioned on tld anymore.
> Tag f:view has id, rendered and binding which it should not.
>
The same applies:
* @JSFJspProperty name = "rendered" returnType = "boolean" tagExcluded =
"true"
* @JSFJspProperty name = "binding" returnType = "java.lang.String"
tagExcluded = "true"
* @JSFJspProperty name = "id" returnType = "java.lang.String" tagExcluded =
"true"
> Tag h:inputTextarea previously had "datafld", "datasrc", "dataformatas".
> These are no longer there, but they do not exist in the sun docs either.
>
I ignore if this attributes will ever work (there are defined on tomahawk
but the docs says "reserved for future usage" or no description). The best
is remove it from tld (like is suggested in the old
org.apache.myfaces.shared_impl.taglib.html.HtmlInputTextareaTagBase).
> Tags h:message/h:messages previously had "dir", "lang" attributes, and a
> set of "onmouse*", "onkey*" attributes. These are no longer there, but
> they do not exist in the sun docs either.
>
The jsf 1.1 spec doc does not define explicitly the attributes, but I
suppose that if there are new attributes to be added on original components,
this should be done on tomahawk (like is happening right now).
>
> I'll try to look into these myself if I can find time. But if anyone
> wants to deal with them first, please do!
>
> Regards,
> Simon
>
>
I'll commit the solution to the problems detected
regards
Leonardo Uribe