Design Discussions

[cagatay.civici]

Shouldn't TargetableFacesMessage's target property be a string referring to the client id of the message component like message, messages, growl?

[tandraschko]

Currently not but it would be a cool feature!

[Oleg]

Shouldn't TargetableFacesMessage's target property be a string referring to the client id of the message component like message, messages, growl?

Good idea. This would be even more flexible and allow to have multiply message components of the same type (message, messages, growl) in updated page region. On the other hand it's a rare case. We normally update one message component of a certain type only.

[cagatay.civici]

I really like setting specific severities to message components, I've seen a post where a user wants to display errors on p:messages and success with growl. escaping is also useful.

Not sure about TargetableFacesMessage, what is the use case?

[Oleg]

Not sure about TargetableFacesMessage, what is the use case?

This is the most useful feature (at least for me). I should target some messages for p:growl and some for p:message(s). I have dynamic includes and I update the entire content area for dynamic includes. Imagine something like

Code: Select all

<h:panelGroup id="myChangableContent">
    <ui:include src="#{myNavigationBean.currentPath}"/>
</h:panelGroup>

What I update is the panel group with id "myChangableContent". This panel group contains p:growl as well as p:message(s). What for message type (growl or message(s)) to be updated is decided server-side. Imagine UI masks which are changed via #{myNavigationBean.currentPath}. We're going from one mask to another with save operation and save was successfull or has failed ==> message should be shown as p:growl (always change the mask). We're staying on the same mask with another save operation with success or fail ==> message should be shown embedded as p:message. I had this code

Code: Select all

	<h:panelGroup id="growlNotification" layout="block">
		<p:growl showDetail="true" showSummary="true" rendered="#{not empty requestScope['growlOnly'] and requestScope['growlOnly'] == true}"/>
	</h:panelGroup>

	<h:panelGroup id="messagesPanelGroup" layout="block" styleClass="messages">
		<p:messages showSummary="true" showDetail="true" rendered="#{empty requestScope['growlOnly'] or requestScope['growlOnly'] != true}">
			<p:effect type="pulsate" event="load">
				<f:param name="mode" value="'show'"/>
				<f:param name="times" value="1"/>
			</p:effect>
		</p:messages>
	</h:panelGroup>

and had to place "growlOnly" in request scope what is not nice. Did I explain understandable, Cagatay? Maybe Thomas has another examples.

[cagatay.civici]

I tried to avoid introducing a new api like TargetableFacesMessage to implement this as JSF already can target messages to a specific component like as we all know;

Code: Select all

FacesContext.addMessage(key, message);

So I've added "for" attribute to growl and messages;

Code: Select all

<p:messages for="somekey" />
<p:growl for="anotherkey" />
<p:growl globalOnly="true" />

context.addMessage("somekey", new FacesMessage(FacesMessage.SEVERITY_INFO,"Sample info message", "PrimeFaces rocks 1"));
context.addMessage("somekey", new FacesMessage(FacesMessage.SEVERITY_INFO,"Sample info message", "PrimeFaces rocks 2"));

context.addMessage("anotherkey", new FacesMessage(FacesMessage.SEVERITY_INFO,"Sample info message", "PrimeFaces rocks 3"));
        
context.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO,"Sample warn message", "Watch out for PrimeFaces!"));

First 2 messages will be displayed by the message, 3rd one by growl and the last one by the second growl, note that globalOnly is set true not do display first 3 messages. keys doesn't have to be a client id of a component, could be any string. I think this will do the job, standard h:messages also have for attribute to implement sth similar, I think FacesMessage should be decoupled with message components.

[Oleg]

All right. Binding FacesMessage <--> tag via "for" attribite in UI is ok.

[tandraschko]

but what's with "messages" tag? it already has a for attribute.

[cfr]

I hope that design is the right topic. I am working on a new component for primefaces extensions. To reduce dupliacte code in the primefaces-extensions.taglib.xml I would recommend to store recurring attributes like primefaces already does. Recurring attributes like id, rendered and binding are stored in the standard_uicomponent_attributes.xml and are used as an entity in the taglib.xml.

[Oleg]

Hi Christoph. This will not work. We don't generate tag lib. at build time. All attribute should be present there. Inheritance is not possible.