In list.xhtml.ftl, what is the point of the foreach for the create button if Pages.applyConvertedValidatedValuesToMode cannot deal with nulls in parameters?
by Francisco Jose Peredo
Hi!
The code for the create button in list.xhtml.ftl looks like this:
<s:div styleClass="actionButtons" rendered="${'#'}{empty from}">
<s:button view="/${editPageName}.xhtml"
id="create"
propagation="none"
value="Create ${componentName}">
<#assign idName = componentName + pojo.identifierProperty.name?cap_first>
<#if c2j.isComponent(pojo.identifierProperty)>
<#foreach componentProperty in
pojo.identifierProperty.value.propertyIterator>
<#assign cidName = componentName + componentProperty.name?cap_first>
<f:param name="${cidName}"/>
</#foreach>
<#else>
<f:param name="${idName}"/>
</#if>
</s:button>
</s:div>
That generates a <f:param name="${idName}"/> for the primarykey(s). Why
is that done? My best guess is that it is to clear the value
of the primary key for the new object that is going to be created.
But the <f:param name="${idName}"/> actually does nothing, because in
seam it is impossible to set a parameter to null. This f:params are
AFAIK expected to set the method generated in EntityHome.java.ftl:
public void set${idName}(${idType} id)
{
setId(id);
}
But that set is never going to be called for <f:param name="${idName}"/>
because the id value is null! And there is code to prevent
set${idName}(${idType} id) from being called if the value for the id is
going to be null in Pages.applyConvertedValidatedValuesToMode:
private void applyConvertedValidatedValuesToModel(FacesContext facesContext)
{
String viewId = getViewId(facesContext);
for ( Page page: getPageStack(viewId) )
{
for ( Param pageParameter: page.getParameters() )
{
ValueExpression valueExpression =
pageParameter.getValueExpression();
if (valueExpression!=null)
{
* Object object = Contexts.getEventContext().get(
pageParameter.getName() );
if (object!=null) //<--- HERE IS THE PROBLEM
{
valueExpression.setValue(object);
}*
}
}
}
}
Of course, it gives the impression it works, but that is just because
our EntityHome is recently created and the value for the Id is initially
null. But if we place our EntityHome inside a LRC, and try to use after
a previous creation set the value of the Id, we will see that the Id is
not reset to null by the <f:param name="${idName}"/>
A workaround I use when the id is Integer is this the -1 value:
<f:param name="${idName}" value="-1"/>
public void set${idName}(${idType} id)
{
if(id<0){
setId(null);
}else{
setId(id);
}
}
But that, as it was commented in another null related discussion, a
really ugly way to deal with stuff we want to be "undefined". So what
can be done to fix this in Seam/seam-gen? (And of course offer a
solution that can be used as a "best practice" for dealing with this
even in applications that do not use seam-gen).
I propose removing the if (object!=null) from
applyConvertedValidatedValuesToModel (and maybe other methods in Pages
that avoid dealing with nulls in the same limited way? like perhaps
convertAndValidateStringValuesInPageContext? and
getStringValuesFromModel? and storeRequestStringValuesInPageContext? and
possibly others...).
Now, if ignoring null values for page parameters in this way is not a
bug, but a feature, then I propose removing the foreach for the create
button list.xhtml.ftl, because it just creates the false impression
that <f:param name="${idName}"/> actually does something.
I already created a related JIRA a while ago
(https://jira.jboss.org/jira/browse/JBSEAM-3693) but guess I was not
able to correctly explain this problem, I hope to have better luck this
time.
Regards,
Francisco Peredo
--
Dirección Informática de Servicios Financieros
Dirección General de Modernización e Innovación Gubernamental
Secretaría de Administración y Finanzas
Paseo de la Sierra 435 col. Reforma
C.P. 86086, Villahermosa, Tabasco.
Tel. 52 + 993 + 310 40 00 Ext. 7127
http://saf.tabasco.gob.mx/
IMPORTANTE: Esta transmisión electrónica, incluyendo sus anexos, archivos insertados o "attachments", puede constituir información confidencial o reservada, en los términos de la Ley de Acceso a la Información Pública del Estado de Tabasco, y estar protegida por el derecho fundamental a la privacidad. Se prohibe el uso de esta información por cualquier persona distinta al receptor intencional o previsto. Si usted ha recibibido esta transmisión electrónica por error, por favor responda inmediatamente al emisor y borre esta información de su sistema. El uso, diseminación, distribución o reproducción de esta transmisión electrónica por receptores no intencionados o no previstos por el emisor, no está autorizada y puede considerarse ilícita en los términos de la legislación penal y civil vigente.
15 years, 10 months
Adding a security audit to the Seam QA (release) process
by Pete Muir
Hi Marc,
Something that we've been discussing is the idea creating a security
audit checklist that will cover Seam and the ways it interacts with
the outside world; initially, we want to focus on JSF, Seam Remoting
(Ajax) and Servlet but we will also consider adding in WS including
JAX-RS, Wicket, GWT and perhaps others, though these are what I can
think off. This checklist would then be added to the Seam QA process
(which is run through at release time).
We were wondering if you would be able to work with us on this? My
suggestion is, that as you (I hope ;-) have a good understanding of
the general approaches that could be used to exploit a Seam that you
would be to work with us both on an initial list of areas to focus on,
and then help us develop the checklist.
Let us know :)
Pete
15 years, 10 months
To cascade or not...
by Max Rydahl Andersen
Hey,
Last week I "fixed" Hibernate tools by adding support for controlling cascade, insert, update and a few other things on associations.
In that progress I noticed that the reverse engineering were setting all collection associations cascade to "all" and not "none" which I believe would be the better to avoid surprises.
I changed it to 'none' since our hbm.xml generation were not generating cascade at that point anyway, but of course when coming to seam-gen we use annotations and in here CascadeType.ALL were being output - with the new hibernate tools no cascade is set because CascadeType.NONE is the default.
This is of course a change in the semantics of generation and I just want to check what we would *really* like to do...
1) does this change actually break seam-gen in any way ? (I don't think so because all assocations is explicitly updated anyway (afaics))
2) What default do you think we should use for reveng, ALL or NONE (or something else ?)
p.s. A swift reply would be appreciated since we are going for a GA build within a few days ;)
p.p.s. If we find a better default I can add a checkbox in the tools to enable to old default if needed.
p.p.p.s. For Pete: The bug I mentioned last night was simply another indentifier misspelling we found that for some
reason hadn't been patched in our build - so that is a separate issue I'm trying to find the cause for in https://jira.jboss.org/jira/browse/JBIDE-3880
Thanks,
Max
15 years, 11 months
Form, Input Elements and SeamText
by Nick Belaevski
Christian,
I've asked Pete a few questions about SeamText and he said I should ask you
about one...
Exploring SeamText 2.1.0.beta1 ANTLR grammar we've discovered that
form/input elements are legal to use, so it is valid to write:
<form action="http://somesite.com"><input type="file" /><input type="submit"
/></form>
I suppose it is not safe that the user is possible to type in forms. What do
you think about it?
Best regards,
Nick Belaevski
15 years, 11 months
cascade or not ?
by Max Rydahl Andersen
Hey,
Last week I "fixed" Hibernate tools by adding support for controlling cascade, insert, update and a few other things on associations.
In that progress I noticed that the reverse engineering were setting all collection associations cascade to "all" and not "none" which I believe would be the better to avoid surprises.
I changed it to 'none' since our hbm.xml generation were not generating cascade at that point anyway, but of course when coming to seam-gen we use annotations and in here CascadeType.ALL were being output - with the new hibernate tools no cascade is set because CascadeType.NONE is the default.
This is of course a change in the semantics of generation and I just want to check what we would *really* like to do...
1) does this change actually break seam-gen in any way ? (I don't think so because all assocations is explicitly updated anyway (afaics))
2) What default do you think we should use for reveng, ALL or NONE (or something else ?)
p.s. A swift reply would be appreciated since we are going for a GA build within a few days ;)
p.p.s. If we find a better default I can add a checkbox in the tools to enable to old default if needed.
p.p.p.s. For Pete: The bug I mentioned last night was simply another indentifier misspelling we found that for some
reason hadn't been patched in our build - so that is a separate issue I'm trying to find the cause for in https://jira.jboss.org/jira/browse/JBIDE-3880
Thanks,
Max
15 years, 11 months
Re: [seam-dev] Re: Form, Input Elements and SeamText
by Dan Allen
Christian,
You reminded me of a very valuable feature of Seam Text, one I think is
worth emphasizing more: sanitation. This is too oft
Perhaps the direction to take is to allow Seam Text to support different
dialects of wiki markup. That would be separate from the general cleaning
that it does which is very much reusable. Seam Text would just have to set
aside some patterns for basic elements that different dialects define
differently. Of course, you would never expose the different dialects to the
user...it would be a global setting for sure.
I certainly don't expect Seam Text to abstract every last syntax out
there...just a handful of the ones that show up most often...giving the
developer a short menu of options to go with...and possibility extend. WDYT?
-Dan
On Fri, Feb 27, 2009 at 7:43 PM, Christian Bauer
<christian.bauer(a)gmail.com>wrote:
> I think the Seam Text really has two somewhat orthogonal features:
>
> - Seam text markup in a proprietary language that might make sense for
> some one-off feature requests, when you really need it.
>
> - A validated and sanitized subset of HTML; you can use the Seam Text
> parser and feed it HTML input, and it will tell you if it's XSS safe
> or not. If you have some rich client text editor that produces HTMl,
> that is useful.
>
> I'm not sure we should do anything more/less than that inside Seam.
>
> On Fri, Feb 27, 2009 at 6:33 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> > I'm digging up an old thread here...
> >
> > Would it be possible for the tinyMCE component to output a more standard
> > wiki syntax as well, such as textile
> > (http://www.textism.com/tools/textile/)? As complete as it may be, the
> Seam
> > formatted text is yet another wiki syntax and the world has so many
> already.
> > For people using Seam in an existing system/environment, it may be
> necessary
> > to adapt. We can't support every syntax, but we can pick the most
> prevalent.
> >
> > Also, when I imagine how this component would work, I figured that all
> the
> > conversation is handled by the JSF life cycle.
> >
> > When the editor is loaded wiki text is converted to html and displayed in
> > the TinyMCE editor
> > When the form is saved, the html is converted to wiki text and copied
> back
> > to the model
> >
> > You do stand to lose some control with this approach if the wiki syntax
> has
> > special hooks. But then again, if someone wants that contorl, I suppose
> they
> > can just edit the wiki text directly.
> >
> > -Dan
> >
> > On Fri, Oct 3, 2008 at 8:07 AM, Jay Balunas <tech4j(a)gmail.com> wrote:
> >>
> >> Hi Christian,
> >>
> >> They are developing a richfaces component that implements tinyMCE
> >> (http://tinymce.moxiecode.com/) as a JSF component.
> >>
> >> The goal is that it also supports seam text conversion on the server
> side
> >> (afaict) which is why they are bringing up questions on proper
> conversion.
> >>
> >> Two places where I have run into the issue below is when creating an
> >> outline/draft document that I am not ready to post, but want to save,
> the
> >> other is when I have a section that I do not need introduction text for
> and
> >> would instead like to begin the first sub-section immediately.
> >>
> >> +header 1
> >> ++header 2
> >>
> >> Is this a change to seam text grammar that would be acceptable?
> >>
> >> -Jay
> >>
> >>
> >> On Fri, Oct 3, 2008 at 8:37 AM, Christian Bauer <cbauer(a)redhat.com>
> wrote:
> >>>
> >>> On Oct 03, 2008, at 14:33 , Ilya Shaikovsky wrote:
> >>>
> >>>> html allows us to use next code
> >>>>
> >>>> <h1>header 1<h1>
> >>>> <h2>header 2<h2>
> >>>>
> >>>> but next code
> >>>>
> >>>> +header 1
> >>>> ++header 2
> >>>
> >>> It wasn't done on purpose but I'm quite happy with requiring text
> between
> >>> headlines. That's how real texts are written, it's good style.
> >>>
> >>>> How about your opinion on this?
> >>>
> >>> I have no idea what you guys are doing but if you want to submit
> >>> reasonable changes to the seam-text.grammar, go
> >>> ahead._______________________________________________
> >>> seam-dev mailing list
> >>> seam-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/seam-dev
> >>
> >>
> >>
> >> --
> >> blog: http://in.relation.to/Bloggers/Jay
> >>
> >> _______________________________________________
> >> seam-dev mailing list
> >> seam-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/seam-dev
> >>
> >
> >
> >
> > --
> > Dan Allen
> > Senior Software Engineer, Red Hat | Author of Seam in Action
> >
> > http://mojavelinux.com
> > http://mojavelinux.com/seaminaction
> >
> > NOTE: While I make a strong effort to keep up with my email on a daily
> > basis, personal or other work matters can sometimes keep me away
> > from my email. If you contact me, but don't hear back for more than a
> week,
> > it is very likely that I am excessively backlogged or the message was
> > caught in the spam filters. Please don't hesitate to resend a message if
> > you feel that it did not reach my attention.
> >
> > _______________________________________________
> > seam-dev mailing list
> > seam-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/seam-dev
> >
> >
>
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 11 months
Chatroom example broken?
by Jozef Hartinger
Hi all,
I am trying to run chatroom example built from trunk. It deploys, I can
log in but messages are not delivered at all. Nor on JBoss 4 neither on
5. Has anyone made some changes to the example or seam-remoting recently?
--
Jozef Hartinger
Seam QA Engineer
Office phone: +420 532 294 130, ext 82-62 130
Mobile phone: +420 608 357 852
E-mail: jharting(a)redhat.com
15 years, 12 months
