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.
16 years, 9 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
16 years, 9 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
16 years, 9 months
Plans for next 2.0.x release?
by Michael Youngstrom
I was wondering what the plans are for the next 2.0.3 release? I'm
stuck with 2.0.x for a few more months and there are quite a few fixes
in that branch that would be nice to have for my projects.
Thanks,
Mike
17 years
EJB3 Releases
by Andrew Lee Rubinger
I've released:
jboss-ejb3-as-int:1.0.0-Beta11
jboss-ejb3-plugin-1.0.0-Alpha1
...and their dependencies.
These have been updated in AS trunk and Branch_5_0. I'm still waiting
on the Hudson results from the larger TestSuites.
Seam guys, you now have a proper dependency in the form of the Plugin.
Anil, this will bring into AS the security manager support we'd
discussed a couple weeks back.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
17 years
Dan out of town
by Dan Allen
FYI. I'll be out of town on vacation this week (Dec 15th - 19th).
-Dan
--
Dan Allen
Software consultant | 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.
17 years
svn:eol-style for docs
by Pete Muir
Please remember to set the svn:eol-style to native for any new
docbook .xml files you commit (this ensures the linefeeds are correct
on all platforms).
17 years
Returned mail: see transcript for details
by MAILER-DAEMON
The original message was received at Sat, 13 Dec 2008 01:00:44 +0200
from [152.219.133.11]
----- The following addresses had permanent fatal errors -----
<seam-dev(a)lists.jboss.org>
----- Transcript of the session follows -----
... while talking to server 10.182.162.28:
>>> RCPT To:<seam-dev(a)lists.jboss.org>
<<< 550 MAILBOX NOT FOUND
17 years
Khhdecakvvhon
by Post Office
This message was undeliverable due to the following reason:
Your message could not be delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 4 days:
Host 168.144.192.249 is not responding.
The following recipients did not receive this message:
<seam-dev(a)lists.jboss.org>
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
17 years
