When a component is not found should Seam warn or fail?

[jbmadair]

Current it appears that when a Seam component is not found Seam will spit out a debug message if debug is turned on. Otherwise it will just fail silently.

I can't figure out if I'm just not seeing the big picture, but it seems like this should fail or at least warn instead of debug. Am I missing something? It's pretty easy to mispell component names, and on a complex page or layout it would be easy to miss errors like that. Perhaps it could be an option?

[jbmadair]

I should have more clearly said that the current behavior for Seam is to continue silently, not fail.

On a page with a incorrect component name, this just displays blank for that expression, without other indications.

[gavin.king]

How on earth is Seam supposed to know that you mis-spelled a component name!?

Context variables are allowed to hold values that are not Seam components.

[jbmadair]

Good point, and that was the missing link that explains it to me.

On the other hand, at the EL level shouldn't the non-existence of a referenced context variable typically indicate an error condition? I know it's not all that uncommon to be rather sloppy with the contexts, but aren't these vars essentially globals? (Even taking into account "scope", which obviously is not the same narrow as lexical scope in the context of source-level code blocks.)

Apologies in advance for my denseness if I'm just missing more obvious explanations =)

[cptnkirk]

The thing about this is that null or not found is a valid use case. Many ppl have pages that rely on this functionality to not display something when a variable isn't in context and then to "come alive" once an action puts this variable into context. In this case you wouldn't want a log message every time, and it's impossible for Seam to know if you're doing this on purpose or by mistake.

In practice, with incremental page design and testing, typos are found quickly and are easily fixed. However, given the amount of typo errors we see on the forums, maybe step #1 if you're having a problem would be to double check your spelling. Yea, it's easy to do, but how can Seam really help with that aside from the debug output already provided?

An option to promote this debug output to warn in web.xml or seam.properties?

[christian.bauer]

I would agree that some improved kind of debugging of this is needed, it is definitely an important issue when you are starting to use Seam. Also, I know how and why the current code spits out dozens of lines of "looking for", "found", and "not found" messages for variable resolution, but I also experienced that I spend a lot of time searching through these not very distinct messages, looking for my variable.

I'd say you currently have to enable DEBUG logging for org.jboss.seam to write an application.

[maxandersen]

Is there anything in EL that allows you to force existence of a variable ?

This is similar to the struggles i had with velocity vs freemarker.

Velocity assumes non-existence is ok and just output null where as FreeMarker takes the opposite stance and complains if it does not exist plus having syntax for allowing you to provide the default in case of "non-existence".

I like the freemarker way much better since you are explicit about wether null/not-there is expected or not.

In any case, providing a way for an EL expression to say "this variable should/must be here" + a decent exception message in case it is not, would be a good help to everyone trying to write an application.

[gavin.king]

Is there anything in EL that allows you to force existence of a variable ?

Just write a JSP custom tag:

<my:assert expression="#{not empty foo}"/>

[gavin.king]

One approach would be to require explicit declaration of all context variables. Many scripting languages have this as an option for global variables. So in components.xml, you could write:

<variables implicit="none">
 <variable name="bar"/>
 <variable name="foo" scope="conversation" type="Foo"/>
</variables>

This would eliminate problems of misspellings, and reduce problems of namespace conflicts