Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JavaServer Faces » Validation: containment-constraint
Validation: containment-constraint [message #473996] Tue, 27 March 2007 15:37 Go to next message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
Hi,

A few questions re containment-constraint rules in jsf_html.xml:

- All tags require a 'view'. Why? What about fragments, for example, that could have a subview
at the root level, or neither if subview is in the "master" page that includes the fragment?

- Only commandButton and commandLink require a form. Why? What about all UIInput components?
Re: Validation: containment-constraint [message #474001 is a reply to message #473996] Tue, 27 March 2007 19:04 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
You make some good points Yury. The containment-constraint support is
still very early in its design cycle, so I welcome any input or changes
you would like to propose as to how to solve these problems better.

To address your specific questions:

> - All tags require a 'view'. Why? What about fragments, for example, that
> could have a subview

Yes, this is good point. At the present time, we don't have a way to
differentiate between stand-alone pages and page fragments that are meant
for inclusion. We also don't have support in WTP (that I am aware of) to
construct a full stand-alone page DOM including subviews, so validating in
the context of a fully constructed page at this stage would require a lot
of work that is not in JSF scope. I suppose we could simply not validate
JSP pages with a jspf extension for example. Do you have any additional
ideas?

> - Only commandButton and commandLink require a form. Why? What about all
> UIInput components?

Based on my own testing with certified 1.1 runtimes (MyFaces and RI),
these two were the only tags that have a hard requirement to be inside an
h:form. Certainly, they were the only ones in the html library that threw
exceptions at runtime when they were not inside an h:form. For example,
you can take the h:inputText, which is probably the most basic UIInput and
drop it inside a view without a form and it seems to render just fine.
Ultimately, this type of validation is aimed at minimizing the number of
times a JSFDeveloper sees incomprehenisible log traces while developing,
without adding too much noise in the form in the false validation.

But I welcome an approach if you want to propose one.


--Cam
Re: Validation: containment-constraint [message #474016 is a reply to message #474001] Wed, 28 March 2007 10:26 Go to previous messageGo to next message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/27/2007 7:04 PM, Cameron Bateman wrote:
> You make some good points Yury. The containment-constraint support is
> still very early in its design cycle, so I welcome any input or changes
> you would like to propose as to how to solve these problems better.
>
> To address your specific questions:
>
>> - All tags require a 'view'. Why? What about fragments, for example, that
>> could have a subview
>
> Yes, this is good point. At the present time, we don't have a way to
> differentiate between stand-alone pages and page fragments that are meant
> for inclusion. We also don't have support in WTP (that I am aware of) to
> construct a full stand-alone page DOM including subviews, so validating in
> the context of a fully constructed page at this stage would require a lot
> of work that is not in JSF scope. I suppose we could simply not validate
> JSP pages with a jspf extension for example. Do you have any additional
> ideas?

I would think that checks like presence of the f:view should be separate from
validation of individual tag. After all, if you forgot a view, would you like
to see one warning per file or many (one per tag).

There are a number of validation rules that could be applied at the validateFile
level, not in validateTag. Validating that all jsf tags are wrapped in a view
for a non-fragment jsp could be one. Checking for duplicate ids withing the same
naming container could be another.

If there is no support for fragments in WTP right now, it would still make sense
to add some kind of extensible isFragment check, so that WTP consumers that do have
fragment support (such as RAD, for example) could turn off "view as root" check.


>> - Only commandButton and commandLink require a form. Why? What about all
>> UIInput components?
>
> Based on my own testing with certified 1.1 runtimes (MyFaces and RI),
> these two were the only tags that have a hard requirement to be inside an
> h:form. Certainly, they were the only ones in the html library that threw
> exceptions at runtime when they were not inside an h:form. For example,
> you can take the h:inputText, which is probably the most basic UIInput and
> drop it inside a view without a form and it seems to render just fine.
> Ultimately, this type of validation is aimed at minimizing the number of
> times a JSFDeveloper sees incomprehenisible log traces while developing,
> without adding too much noise in the form in the false validation.

I see your point, if the purpose of validation is to inform the user of potential
"explosions" at runtime. I wouldn't agree with that purpose though. I'd say validation
should inform the user of common potential mistakes that can cause the application
not to work.

As far as I remember RI, only commandLink renderer requires the form. commandButton does not
and wouldn't throw an exception. Not sure about MyFaces. For example, a commandButton with
type="button" does not need a form and should render fine in any case.

At the same time, an inputText outside a form renders fine, but in 99% it won't
do anything, thus becoming totally useless. And if a user is to build his page
like this:

<view>
<inputText />
<form>
<commandButton />
</form>
</view>

validation wouldn't warn him, no exceptions will be thrown at runtime, yet the
application won't work and the user will be totally lost at why.

Arguably, this is more important is useful for the end user, than preventing log traces
(when there is a log trace, at least the user knows something is wrong).


Additionally, I believe containment validation should work both ways, not only looking
at parents. Consider these checks:
- f:facet can have only one child
- h:form can not have a nested h:form
- h:select* can have only f:selectItem and f:selectItems children
etc

I am not really familiar with xpath, so I don't know if such constraints can already be formulated
in the metadata. Can they? But even if they can, the error message always talks about the parent:
"Tag {0} is missing required parent tag \"{1}\" ({2})" (and it does not seem to be externalized, btw).


And on another side note, I noticed that boolean attributes aren't validated for being either
"true" or "false", due to the way BooleanType#isValidValue works (there is a TODO there).
Again, it is technically correct to allow any string, which would be treated as "false",
but if the user made a typo and entered disabled="tru", that's exactly where he'd need
validation to warn him that "tru" may not be right. Otherwise he'd spend hours looking
for a reason why his component isn't disabled at runtime, at spotting a type in a large
JSP tag is anything but easy.
Re: Validation: containment-constraint [message #474020 is a reply to message #474016] Wed, 28 March 2007 14:34 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
> I would think that checks like presence of the f:view should be separate
> from validation of individual tag. After all, if you forgot a view, would
> you like to see one warning per file or many (one per tag).

How does the validator know that the programmer has forgotten an f:view
tag until it has checked every tag to see if any of them are JSF tags that
it knows enough about (i.e. meta-data) to be sure that they require an
f:view wrapping them?

> Checking for duplicate ids withing the same naming container could be
> another.

But when you a find a duplicate, where would expect that the conflict was
decorated? Wouldn't it be on the tags that have duplicate ids instead of
just the whole file?

> If there is no support for fragments in WTP right now, it would still make
> sense to add some kind of extensible isFragment check, so that WTP
> consumers that do have fragment support (such as RAD, for example) could
> turn off "view as root" check.

Makes sense. JSP validator has an "isFragment" check although it is not
API and seems fairly heuristic. Through what mechanism could I enable it
so that consumers could use it in a uniform way?

> I'd say validation should inform the user of
> common potential mistakes that
> can cause the application not to work.

I agree when we can be sure that a mistake has been made. In this case,
the page will run. If we can create an additional "lint" mode, then we
could add things that may or may not be a mistake. But right now, we
don't even have the UI necessary for the user to disable/change severity
of the diagnostics we do report.

One other point is that with the merge mechanism in our meta-data
framework, you can add non-conflicting meta-data checking for f:view
around other tags in your own implementation. Or you can drop the
tagsupport plugin and use only your own meta-data.

> As far as I remember RI, only commandLink renderer requires the form.

This matches my testing, but MyFaces reports for a commandButton:

javax.faces.FacesException: Component _idJsp0 must be embedded in an form

> At the same time, an inputText outside a form renders fine, but in 99% it
> won't do anything, thus becoming totally useless.

That's a good point. This is something I will look into adding once we
are able to give the user more control over what problems are reported.
Alternatively, as I said, you are free to make your own decisions if you
are doing your own implementation.

> I am not really familiar with xpath, so I don't know if such constraints
> can already be formulated
> in the metadata. Can they? But even if they can, the error message always

Currently no. This feature is still quite immature and was constructed
mainly as a preview for EclipseCon. The system can be made more flexible
to validate the types of checks you want.

> Again, it is technically correct to allow any string, which would be
> treated as "false", but if the user made a typo and entered disabled="tru",
> that's exactly where he'd need validation to warn him that "tru" may not be
> right.

Agreed.


--Cam
Re: Validation: containment-constraint [message #474074 is a reply to message #474020] Wed, 28 March 2007 15:27 Go to previous messageGo to next message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/28/2007 2:34 PM, Cameron Bateman wrote:

> How does the validator know that the programmer has forgotten an f:view
> tag until it has checked every tag to see if any of them are JSF tags that
> it knows enough about (i.e. meta-data) to be sure that they require an
> f:view wrapping them?

Find the very first jsf tag and see if it's a view?

>> Checking for duplicate ids withing the same naming container could be
>> another.
>
> But when you a find a duplicate, where would expect that the conflict was
> decorated? Wouldn't it be on the tags that have duplicate ids instead of
> just the whole file?

On the tags would be nicer, but it would require tag validation to know about
other tags around it, which I thought may be easier to tackle on the file level.


> Makes sense. JSP validator has an "isFragment" check although it is not
> API and seems fairly heuristic. Through what mechanism could I enable it
> so that consumers could use it in a uniform way?

Oh, good, didn't know that method existed. I think checking isFragment() could
be enough, assuming file's ContentType has been set correctly.

Generally though, I'd say that dropping view requirement all together may be not that
bad of an idea. It is quite common to have included jsps, tiles and similar fragments.
Having every single jsf tag in such pages marked as a warning... talk about false
positives! :) At least, if it was on the file level and reported once (as discussed above),
it would be bearable.

> But right now, we
> don't even have the UI necessary for the user to disable/change severity
> of the diagnostics we do report.

That would be a great and very useful addition! Any plans?

> One other point is that with the merge mechanism in our meta-data
> framework, you can add non-conflicting meta-data checking for f:view
> around other tags in your own implementation. Or you can drop the
> tagsupport plugin and use only your own meta-data.

True. However, we'd love to reuse as much as possible when building on top
of WTF JSF, so dropping a plugin isn't really what we are after. We'd love
to include it and at the same time make it better for everybody's benefit.

With the merge mechanism, is there a way to overwrite checking for f:view
for h: tags w/o dropping tagsupport plugin? I think the answer is "no",
but let me make sure.

>> As far as I remember RI, only commandLink renderer requires the form.
>
> This matches my testing, but MyFaces reports for a commandButton:
>
> javax.faces.FacesException: Component _idJsp0 must be embedded in an form

Maybe this is something MyFaces needs to fix?

>> Again, it is technically correct to allow any string, which would be
>> treated as "false", but if the user made a typo and entered disabled="tru",
>> that's exactly where he'd need validation to warn him that "tru" may not be
>> right.
>
> Agreed.

This looks like an easy fix. Do you want me to open a bug?
Re: Validation: containment-constraint [message #474078 is a reply to message #474074] Wed, 28 March 2007 18:51 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
> Having every single jsf tag in such pages marked as a warning... talk about
> false positives! :) At least, if it was on the file level and reported once
> (as discussed above), it would be bearable.

I see your point and mostly agree. I have created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179868 to track.

>> don't even have the UI necessary for the user to disable/change severity
> That would be a great and very useful addition! Any plans?

It's more a question of when than if at this point.

> With the merge mechanism, is there a way to overwrite checking for f:view
> for h: tags w/o dropping tagsupport plugin? I think the answer is "no",
> but let me make sure.

You're right, disabling something already there isn't supported currently.

>> javax.faces.FacesException: Component _idJsp0 must be embedded in an form
> Maybe this is something MyFaces needs to fix?

Hmm.. I can't find anything in the spec one way or the other, so I'm not
sure it can really be called a bug. Actually MyFaces logs a warning for
h:inputText's not in h:form's.

> This looks like an easy fix. Do you want me to open a bug?

Thanks, that would be great.


--Cam
Re: Validation: containment-constraint [message #474081 is a reply to message #474078] Wed, 28 March 2007 20:40 Go to previous messageGo to next message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/28/2007 6:51 PM, Cameron Bateman wrote:

> Actually MyFaces logs a warning for h:inputText's not in h:form's.

And I believe design-time validation should too.


>> This looks like an easy fix. Do you want me to open a bug?
>
> Thanks, that would be great.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=179881
Re: Validation: containment-constraint [message #476120 is a reply to message #474081] Thu, 30 April 2009 08:16 Go to previous messageGo to next message
shilpa is currently offline shilpa
Messages: 24
Registered: July 2009
Junior Member
Cam,

The Containment constraint doesn't seem to work for me when I have written
a plugin for my custom tag library. Even if I mention a constraint of say
actionButton to be inside a form, it still allows me to put an action
button outside a form.
My metadata looks like this -
<?xml version="1.0" encoding="UTF-8"?>
<md:metadatamodel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:md="http://org.eclipse.jst.jsf.common.metadata/metadata.ecore"
xmlns:mdt=" http://org.eclipse.jst.jsf.common.metadata/metadataTraitType s.ecore"
xmlns:cnst="http://org.eclipse.jst.jsf.core/constraints.ecore"
xmlns:qe=" http://org.eclipse.jsf.pagedesigner/QuickEditTabSections.eco re"
id="http://esf.hsbc.com/tags/jhx" type="tagFile">
<!-- Action Button Starts -->
<entity id="actionButton" type="tag">
<include-entity-group id="common-attributes" />
<include-entity-group id="basic-jhx-common-attributes" />
<trait id="containment-constraint">
<value xsi:type="cnst:ContainsTagConstraint">
<set-generator>
<algorithm>xpath</algorithm>
<expression>ancestor::*</expression>
</set-generator>
<satisfies-set>
<tagId>
<uri>http://esf.hsbc.com/tags/jhx</uri>
<name>form</name>
</tagId>
</satisfies-set>
</value>
</trait>



Do u see any problem in this ???
Re: Validation: containment-constraint [message #476125 is a reply to message #476120] Thu, 30 April 2009 21:45 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
The constraint doesn't stop from doing anything. Rather, the tag should
be marked with a warning that it is not instead your form tag when you run
validation (i.e. when you right click on the jsp and select "Validation").
Do you not see this error message?


Thanks,

Cameron

shilpa wrote:

> Cam,

> The Containment constraint doesn't seem to work for me when I have written
> a plugin for my custom tag library. Even if I mention a constraint of say
> actionButton to be inside a form, it still allows me to put an action
> button outside a form.
> My metadata looks like this -
> <?xml version="1.0" encoding="UTF-8"?>
> <md:metadatamodel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> xmlns:md="http://org.eclipse.jst.jsf.common.metadata/metadata.ecore"
>
xmlns:mdt=" http://org.eclipse.jst.jsf.common.metadata/metadataTraitType s.ecore"
> xmlns:cnst="http://org.eclipse.jst.jsf.core/constraints.ecore"
> xmlns:qe=" http://org.eclipse.jsf.pagedesigner/QuickEditTabSections.eco re"
> id="http://esf.hsbc.com/tags/jhx" type="tagFile">
> <!-- Action Button Starts -->
> <entity id="actionButton" type="tag">
> <include-entity-group id="common-attributes" />
> <include-entity-group id="basic-jhx-common-attributes" />
> <trait id="containment-constraint">
> <value xsi:type="cnst:ContainsTagConstraint">
> <set-generator>
> <algorithm>xpath</algorithm>
> <expression>ancestor::*</expression>
> </set-generator>
> <satisfies-set>
> <tagId>
> <uri>http://esf.hsbc.com/tags/jhx</uri>
> <name>form</name>
> </tagId>
> </satisfies-set>
> </value>
> </trait>



> Do u see any problem in this ???
Re: Validation: containment-constraint [message #476130 is a reply to message #476125] Mon, 04 May 2009 00:15 Go to previous message
shilpa is currently offline shilpa
Messages: 24
Registered: July 2009
Junior Member
No Cameron, I can't even see warning messages due to the constraint
Re: Validation: containment-constraint [message #608452 is a reply to message #473996] Tue, 27 March 2007 19:04 Go to previous message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
You make some good points Yury. The containment-constraint support is
still very early in its design cycle, so I welcome any input or changes
you would like to propose as to how to solve these problems better.

To address your specific questions:

> - All tags require a 'view'. Why? What about fragments, for example, that
> could have a subview

Yes, this is good point. At the present time, we don't have a way to
differentiate between stand-alone pages and page fragments that are meant
for inclusion. We also don't have support in WTP (that I am aware of) to
construct a full stand-alone page DOM including subviews, so validating in
the context of a fully constructed page at this stage would require a lot
of work that is not in JSF scope. I suppose we could simply not validate
JSP pages with a jspf extension for example. Do you have any additional
ideas?

> - Only commandButton and commandLink require a form. Why? What about all
> UIInput components?

Based on my own testing with certified 1.1 runtimes (MyFaces and RI),
these two were the only tags that have a hard requirement to be inside an
h:form. Certainly, they were the only ones in the html library that threw
exceptions at runtime when they were not inside an h:form. For example,
you can take the h:inputText, which is probably the most basic UIInput and
drop it inside a view without a form and it seems to render just fine.
Ultimately, this type of validation is aimed at minimizing the number of
times a JSFDeveloper sees incomprehenisible log traces while developing,
without adding too much noise in the form in the false validation.

But I welcome an approach if you want to propose one.


--Cam
Re: Validation: containment-constraint [message #608458 is a reply to message #474001] Wed, 28 March 2007 10:26 Go to previous message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/27/2007 7:04 PM, Cameron Bateman wrote:
> You make some good points Yury. The containment-constraint support is
> still very early in its design cycle, so I welcome any input or changes
> you would like to propose as to how to solve these problems better.
>
> To address your specific questions:
>
>> - All tags require a 'view'. Why? What about fragments, for example, that
>> could have a subview
>
> Yes, this is good point. At the present time, we don't have a way to
> differentiate between stand-alone pages and page fragments that are meant
> for inclusion. We also don't have support in WTP (that I am aware of) to
> construct a full stand-alone page DOM including subviews, so validating in
> the context of a fully constructed page at this stage would require a lot
> of work that is not in JSF scope. I suppose we could simply not validate
> JSP pages with a jspf extension for example. Do you have any additional
> ideas?

I would think that checks like presence of the f:view should be separate from
validation of individual tag. After all, if you forgot a view, would you like
to see one warning per file or many (one per tag).

There are a number of validation rules that could be applied at the validateFile
level, not in validateTag. Validating that all jsf tags are wrapped in a view
for a non-fragment jsp could be one. Checking for duplicate ids withing the same
naming container could be another.

If there is no support for fragments in WTP right now, it would still make sense
to add some kind of extensible isFragment check, so that WTP consumers that do have
fragment support (such as RAD, for example) could turn off "view as root" check.


>> - Only commandButton and commandLink require a form. Why? What about all
>> UIInput components?
>
> Based on my own testing with certified 1.1 runtimes (MyFaces and RI),
> these two were the only tags that have a hard requirement to be inside an
> h:form. Certainly, they were the only ones in the html library that threw
> exceptions at runtime when they were not inside an h:form. For example,
> you can take the h:inputText, which is probably the most basic UIInput and
> drop it inside a view without a form and it seems to render just fine.
> Ultimately, this type of validation is aimed at minimizing the number of
> times a JSFDeveloper sees incomprehenisible log traces while developing,
> without adding too much noise in the form in the false validation.

I see your point, if the purpose of validation is to inform the user of potential
"explosions" at runtime. I wouldn't agree with that purpose though. I'd say validation
should inform the user of common potential mistakes that can cause the application
not to work.

As far as I remember RI, only commandLink renderer requires the form. commandButton does not
and wouldn't throw an exception. Not sure about MyFaces. For example, a commandButton with
type="button" does not need a form and should render fine in any case.

At the same time, an inputText outside a form renders fine, but in 99% it won't
do anything, thus becoming totally useless. And if a user is to build his page
like this:

<view>
<inputText />
<form>
<commandButton />
</form>
</view>

validation wouldn't warn him, no exceptions will be thrown at runtime, yet the
application won't work and the user will be totally lost at why.

Arguably, this is more important is useful for the end user, than preventing log traces
(when there is a log trace, at least the user knows something is wrong).


Additionally, I believe containment validation should work both ways, not only looking
at parents. Consider these checks:
- f:facet can have only one child
- h:form can not have a nested h:form
- h:select* can have only f:selectItem and f:selectItems children
etc

I am not really familiar with xpath, so I don't know if such constraints can already be formulated
in the metadata. Can they? But even if they can, the error message always talks about the parent:
"Tag {0} is missing required parent tag \"{1}\" ({2})" (and it does not seem to be externalized, btw).


And on another side note, I noticed that boolean attributes aren't validated for being either
"true" or "false", due to the way BooleanType#isValidValue works (there is a TODO there).
Again, it is technically correct to allow any string, which would be treated as "false",
but if the user made a typo and entered disabled="tru", that's exactly where he'd need
validation to warn him that "tru" may not be right. Otherwise he'd spend hours looking
for a reason why his component isn't disabled at runtime, at spotting a type in a large
JSP tag is anything but easy.
Re: Validation: containment-constraint [message #608460 is a reply to message #474016] Wed, 28 March 2007 14:34 Go to previous message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
> I would think that checks like presence of the f:view should be separate
> from validation of individual tag. After all, if you forgot a view, would
> you like to see one warning per file or many (one per tag).

How does the validator know that the programmer has forgotten an f:view
tag until it has checked every tag to see if any of them are JSF tags that
it knows enough about (i.e. meta-data) to be sure that they require an
f:view wrapping them?

> Checking for duplicate ids withing the same naming container could be
> another.

But when you a find a duplicate, where would expect that the conflict was
decorated? Wouldn't it be on the tags that have duplicate ids instead of
just the whole file?

> If there is no support for fragments in WTP right now, it would still make
> sense to add some kind of extensible isFragment check, so that WTP
> consumers that do have fragment support (such as RAD, for example) could
> turn off "view as root" check.

Makes sense. JSP validator has an "isFragment" check although it is not
API and seems fairly heuristic. Through what mechanism could I enable it
so that consumers could use it in a uniform way?

> I'd say validation should inform the user of
> common potential mistakes that
> can cause the application not to work.

I agree when we can be sure that a mistake has been made. In this case,
the page will run. If we can create an additional "lint" mode, then we
could add things that may or may not be a mistake. But right now, we
don't even have the UI necessary for the user to disable/change severity
of the diagnostics we do report.

One other point is that with the merge mechanism in our meta-data
framework, you can add non-conflicting meta-data checking for f:view
around other tags in your own implementation. Or you can drop the
tagsupport plugin and use only your own meta-data.

> As far as I remember RI, only commandLink renderer requires the form.

This matches my testing, but MyFaces reports for a commandButton:

javax.faces.FacesException: Component _idJsp0 must be embedded in an form

> At the same time, an inputText outside a form renders fine, but in 99% it
> won't do anything, thus becoming totally useless.

That's a good point. This is something I will look into adding once we
are able to give the user more control over what problems are reported.
Alternatively, as I said, you are free to make your own decisions if you
are doing your own implementation.

> I am not really familiar with xpath, so I don't know if such constraints
> can already be formulated
> in the metadata. Can they? But even if they can, the error message always

Currently no. This feature is still quite immature and was constructed
mainly as a preview for EclipseCon. The system can be made more flexible
to validate the types of checks you want.

> Again, it is technically correct to allow any string, which would be
> treated as "false", but if the user made a typo and entered disabled="tru",
> that's exactly where he'd need validation to warn him that "tru" may not be
> right.

Agreed.


--Cam
Re: Validation: containment-constraint [message #608866 is a reply to message #474020] Wed, 28 March 2007 15:27 Go to previous message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/28/2007 2:34 PM, Cameron Bateman wrote:

> How does the validator know that the programmer has forgotten an f:view
> tag until it has checked every tag to see if any of them are JSF tags that
> it knows enough about (i.e. meta-data) to be sure that they require an
> f:view wrapping them?

Find the very first jsf tag and see if it's a view?

>> Checking for duplicate ids withing the same naming container could be
>> another.
>
> But when you a find a duplicate, where would expect that the conflict was
> decorated? Wouldn't it be on the tags that have duplicate ids instead of
> just the whole file?

On the tags would be nicer, but it would require tag validation to know about
other tags around it, which I thought may be easier to tackle on the file level.


> Makes sense. JSP validator has an "isFragment" check although it is not
> API and seems fairly heuristic. Through what mechanism could I enable it
> so that consumers could use it in a uniform way?

Oh, good, didn't know that method existed. I think checking isFragment() could
be enough, assuming file's ContentType has been set correctly.

Generally though, I'd say that dropping view requirement all together may be not that
bad of an idea. It is quite common to have included jsps, tiles and similar fragments.
Having every single jsf tag in such pages marked as a warning... talk about false
positives! :) At least, if it was on the file level and reported once (as discussed above),
it would be bearable.

> But right now, we
> don't even have the UI necessary for the user to disable/change severity
> of the diagnostics we do report.

That would be a great and very useful addition! Any plans?

> One other point is that with the merge mechanism in our meta-data
> framework, you can add non-conflicting meta-data checking for f:view
> around other tags in your own implementation. Or you can drop the
> tagsupport plugin and use only your own meta-data.

True. However, we'd love to reuse as much as possible when building on top
of WTF JSF, so dropping a plugin isn't really what we are after. We'd love
to include it and at the same time make it better for everybody's benefit.

With the merge mechanism, is there a way to overwrite checking for f:view
for h: tags w/o dropping tagsupport plugin? I think the answer is "no",
but let me make sure.

>> As far as I remember RI, only commandLink renderer requires the form.
>
> This matches my testing, but MyFaces reports for a commandButton:
>
> javax.faces.FacesException: Component _idJsp0 must be embedded in an form

Maybe this is something MyFaces needs to fix?

>> Again, it is technically correct to allow any string, which would be
>> treated as "false", but if the user made a typo and entered disabled="tru",
>> that's exactly where he'd need validation to warn him that "tru" may not be
>> right.
>
> Agreed.

This looks like an easy fix. Do you want me to open a bug?
Re: Validation: containment-constraint [message #608870 is a reply to message #474074] Wed, 28 March 2007 18:51 Go to previous message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
> Having every single jsf tag in such pages marked as a warning... talk about
> false positives! :) At least, if it was on the file level and reported once
> (as discussed above), it would be bearable.

I see your point and mostly agree. I have created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179868 to track.

>> don't even have the UI necessary for the user to disable/change severity
> That would be a great and very useful addition! Any plans?

It's more a question of when than if at this point.

> With the merge mechanism, is there a way to overwrite checking for f:view
> for h: tags w/o dropping tagsupport plugin? I think the answer is "no",
> but let me make sure.

You're right, disabling something already there isn't supported currently.

>> javax.faces.FacesException: Component _idJsp0 must be embedded in an form
> Maybe this is something MyFaces needs to fix?

Hmm.. I can't find anything in the spec one way or the other, so I'm not
sure it can really be called a bug. Actually MyFaces logs a warning for
h:inputText's not in h:form's.

> This looks like an easy fix. Do you want me to open a bug?

Thanks, that would be great.


--Cam
Re: Validation: containment-constraint [message #608875 is a reply to message #474078] Wed, 28 March 2007 20:40 Go to previous message
Yury Kats is currently offline Yury Kats
Messages: 104
Registered: July 2009
Senior Member
On 3/28/2007 6:51 PM, Cameron Bateman wrote:

> Actually MyFaces logs a warning for h:inputText's not in h:form's.

And I believe design-time validation should too.


>> This looks like an easy fix. Do you want me to open a bug?
>
> Thanks, that would be great.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=179881
Re: Validation: containment-constraint [message #618748 is a reply to message #474081] Thu, 30 April 2009 08:16 Go to previous message
shilpa is currently offline shilpa
Messages: 24
Registered: July 2009
Junior Member
Cam,

The Containment constraint doesn't seem to work for me when I have written
a plugin for my custom tag library. Even if I mention a constraint of say
actionButton to be inside a form, it still allows me to put an action
button outside a form.
My metadata looks like this -
<?xml version="1.0" encoding="UTF-8"?>
<md:metadatamodel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:md="http://org.eclipse.jst.jsf.common.metadata/metadata.ecore"
xmlns:mdt=" http://org.eclipse.jst.jsf.common.metadata/metadataTraitType s.ecore"
xmlns:cnst="http://org.eclipse.jst.jsf.core/constraints.ecore"
xmlns:qe=" http://org.eclipse.jsf.pagedesigner/QuickEditTabSections.eco re"
id="http://esf.hsbc.com/tags/jhx" type="tagFile">
<!-- Action Button Starts -->
<entity id="actionButton" type="tag">
<include-entity-group id="common-attributes" />
<include-entity-group id="basic-jhx-common-attributes" />
<trait id="containment-constraint">
<value xsi:type="cnst:ContainsTagConstraint">
<set-generator>
<algorithm>xpath</algorithm>
<expression>ancestor::*</expression>
</set-generator>
<satisfies-set>
<tagId>
<uri>http://esf.hsbc.com/tags/jhx</uri>
<name>form</name>
</tagId>
</satisfies-set>
</value>
</trait>



Do u see any problem in this ???
Re: Validation: containment-constraint [message #618753 is a reply to message #476120] Thu, 30 April 2009 21:45 Go to previous message
Cameron Bateman is currently offline Cameron Bateman
Messages: 480
Registered: July 2009
Senior Member
The constraint doesn't stop from doing anything. Rather, the tag should
be marked with a warning that it is not instead your form tag when you run
validation (i.e. when you right click on the jsp and select "Validation").
Do you not see this error message?


Thanks,

Cameron

shilpa wrote:

> Cam,

> The Containment constraint doesn't seem to work for me when I have written
> a plugin for my custom tag library. Even if I mention a constraint of say
> actionButton to be inside a form, it still allows me to put an action
> button outside a form.
> My metadata looks like this -
> <?xml version="1.0" encoding="UTF-8"?>
> <md:metadatamodel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> xmlns:md="http://org.eclipse.jst.jsf.common.metadata/metadata.ecore"
>
xmlns:mdt=" http://org.eclipse.jst.jsf.common.metadata/metadataTraitType s.ecore"
> xmlns:cnst="http://org.eclipse.jst.jsf.core/constraints.ecore"
> xmlns:qe=" http://org.eclipse.jsf.pagedesigner/QuickEditTabSections.eco re"
> id="http://esf.hsbc.com/tags/jhx" type="tagFile">
> <!-- Action Button Starts -->
> <entity id="actionButton" type="tag">
> <include-entity-group id="common-attributes" />
> <include-entity-group id="basic-jhx-common-attributes" />
> <trait id="containment-constraint">
> <value xsi:type="cnst:ContainsTagConstraint">
> <set-generator>
> <algorithm>xpath</algorithm>
> <expression>ancestor::*</expression>
> </set-generator>
> <satisfies-set>
> <tagId>
> <uri>http://esf.hsbc.com/tags/jhx</uri>
> <name>form</name>
> </tagId>
> </satisfies-set>
> </value>
> </trait>



> Do u see any problem in this ???
Re: Validation: containment-constraint [message #618758 is a reply to message #476125] Mon, 04 May 2009 00:15 Go to previous message
shilpa is currently offline shilpa
Messages: 24
Registered: July 2009
Junior Member
No Cameron, I can't even see warning messages due to the constraint
Previous Topic:Announce: Non-breaking API change in IElementEdit due to bug 267962
Next Topic:Extending Snippets view
Goto Forum:
  


Current Time: Mon Jul 28 00:29:09 EDT 2014

Powered by FUDForum. Page generated in 0.03510 seconds