Design Discussions

[tandraschko]

lools really awesome! cool

[Oleg]

Hi Cagatay,

I know about UITree which mimics UIData behavior. UITree has some shortcomings and is not universal (only for Tree / TreeTable). I have implemented abstract base class AbstractDynamicData which fixes all issues (e.g. implements invokeOnComponent, adds event publishing to processValidators(), optimizes setDate() for iterations over children via saveDescendantState() / restoreDescendantState(), etc.).

See http://code.google.com/p/primefaces-ext ... cData.java

An extension of this abstract class is the concret class DynaForm. This class considers types during iterations what UITree doesn't do.

See http://code.google.com/p/primefaces-ext ... aForm.java

As I said UITree performs many useless iterations and has some issues. You can reuse AbstractDynamicData and implement "UITree extends AbstractDynamicData" similar to "DynaForm extends AbstractDynamicData" in PF Extensions. If you want of course. The mentioned classes were implemented with care and well tested. Effort to implement UITree extending AbstractDynamicData is minimal.

Best regards.

[Oleg]

Forgot to say. One of important things is that model class should calculate key (also known as rowKey). Key calculation should be encapsulated in TreeNode similar to DynaFormControl. At the moment PrimeFaces calculates current key in UITree and TreeRenderer - the same code at different places. This is error-prone (remember DRY concept - don't repeat yourself) and not comfortable for other extensions using the same dynamic behavior. When you write "TreeNode implements KeyData" similar to "DynaFormControl implements KeyData" and provide a method for key calculation (generation), you can use the mentioned above AbstractDynamicData. The method for key calculation (generation) is simple for TreeNode if every tree node provide it. This is key from parent node + separator + key part of current node.

[Oleg]

Hi Cagatay,

Small promotion again. I have proposed here viewtopic.php?f=3&t=22588 to move pe:paginator to the core project. Reason:

1) Reusing the same paginator settings across different data iteration components or also instances of the same type.
2) Lightweight data iteration components with decoupled paginator logic (less exposed attributes in comp. tags).

What do you think?

[cagatay.civici]

That will break backward compatibility?

[Oleg]

Why? I didn't understand. Paginator related attributes in data iteration components will be still here.

But p:dataTable can be a lightweight tag then, paginator related attributes reside in a separate tag. We use it with PF 3.x http://fractalsoft.net/primeext-showcas ... inator.jsf Existing components are not touched, new ones as you want: you can add paginator attrs. too or point to a paginator tag.

This is just a suggestion, no force and no problem if paginator tag remains in Extensions.

[cagatay.civici]

Thanks, let me think about it. Just wanted to make sure paginator attributes stay in data*

[Oleg]

Yes, paginator attributes stay in data*. Think about this

[Oleg]

Hi Cagatay. I have a problem

How can we check reliable if a component is ajaxified (that means it sends AJAX requests)? I use this method:

Code: Select all

	public static boolean isAjaxifiedComponent(UIComponent component) {
		// check for ajax source
		if (component instanceof AjaxSource) {
			// note: we don't call "isAjax" because not all components implementing AjaxSource has "isAjax" method.
			// e.g. HotKey is automatic ajaxified if JS "handler" is not set. It doesn't have "isAjax".
			// how can we check more reliable?
			return true;
		}

		if (component instanceof ClientBehaviorHolder) {
			// check for attached f:ajax / p:ajax
			Collection<List<ClientBehavior>> behaviors = ((ClientBehaviorHolder) component).getClientBehaviors().values();
			if (behaviors == null || behaviors.isEmpty()) {
				return false;
			}

			for (List<ClientBehavior> listBehaviors : behaviors) {
				for (ClientBehavior clientBehavior : listBehaviors) {
					if (clientBehavior instanceof javax.faces.component.behavior.AjaxBehavior
					    || clientBehavior instanceof org.primefaces.component.behavior.ajax.AjaxBehavior) {
						return true;
					}
				}
			}
		}

		return false;
	}

But this is not good enough. See my comments in code. I can call "isAjax" method per Java Reflection, but it doesn't good enough too because e.g. HotKey doesn't have this method and is ajaxified if "handler" == null.

Do you have any tips?

[Oleg]

Every AjaxSource component should implement isAjaxified() contract method.

For CommandButton it's

Code: Select all

    return !type.equals("reset") && !type.equals("button") && button.isAjax();

For CommandLink it's

Code: Select all

    return link.isAjax();

For SplitButton it's

Code: Select all

    return splitButton.isAjax();

For MenuItem it's

Code: Select all

    return menuItem.getUrl() == null && menuItem.isAjax();

For HotKey it's

Code: Select all

    return hotKey.getHandler() == null;

For RemoteCommand and Poll it's

Code: Select all

    return true;

This would be a good design I think. And a big help for component developers. Check for attached AjaxBehavior can be added too.