RSF Discussions Forum

I know this is probably evil...

Anyways, I'm working on this pager, and if I'm at either end of the pager I need the Prev or Next button to be disabled. So I'm going like:

Code:

 UICommand prev = UICommand.make(toppager, "prev", "#{anncviewpager.goAction}");
 		String prevAnncId = util.getPrevAnncID(this.anncid);
 		if ((prevAnncId == null) || (prevAnncId.equals("")))
 		{
 			System.out.println("SWG Doing the UIFreeAttr disabled.");
 			UIFreeAttributeDecorator disabled = new UIFreeAttributeDecorator();
 			disabled.attributes = new HashMap();
 			disabled.attributes.put("disabled","disabled");
 			prev.decorators = new DecoratorList(disabled);
 		}
 		else
 		{	
 			System.out.println("SWG Not doing the UIFreeAttr.");
 			prev.parameters.add(new UIELBinding("#{anncviewpager.direction}", "previous"));
 			prev.parameters.add(new UIELBinding("#{anncviewpager.anncid}", prevAnncId));
 		}

I'll probably be refactoring this out as soon as it works, so it can be used in other pagers without touching the UIFreeAttributeDecorator.

However, I'm getting:
Code:

 SWG Doing the UIFreeAttr disabled.
 Top level form: uk.org.ponder.rsf.components.UIForm@5a4c93e3
 Registering uk.org.ponder.rsf.components.UICommand@5a5a93e3 with toppagerform
 Registering uk.org.ponder.rsf.components.UICommand@593913e3 with toppagerform
 2006-06-11 10:09:57,424 WARN (DecoratorManager.java:37) - <Unable to find renderer for decorator class uk.org.ponder.rsf.components.decorators.UIFreeAttributeDecorator and content type HTML>
 2006-06-11 10:09:58,310 INFO (RootHandlerBean.java:89) - <Request handled>

Am I doing something wrong, or is it not implemented yet? (This is on 0.63)

Also, I noticed that the trunk version for SakaiRSF depends on Sakai 2.2. I'm planning on using Sakai 2.1 for at least another month or two. If I change the properties on the SakaiRSF 0.63 I should be able to mix it with the Ponder/Servlet/RSFUtil trunk right? (as it doesn't depend on much or change things too drastically?)

thx

Yep,
a) this is completely morally wrong, decorators are specced for NON-FUNCTIONAL changes to the component tree, as rendering hints only.
b) this is probably broken, FreeAttr actually had never been tested and I may well have forgotten to add the renderer in the right place.

I'll fix mine if you'll fix yours

Would the philosophically correct way to attack this be in the template, or in a UISomething component?

I suppose for now the best thing to do would be:
Code:

 <input rsf:id="prev:" type="submit" value="Prev" />
 <input rsf:id="prev:" type="submit" value="Prev" disabled="disabled" />

and then if I don't fill in the prev: component it will default to the disabled one?

The template is the right place. Your example there won't quite work because you have given them the same id - so there's no way that the renderer could tell the difference.

You could either make one of them prev:enabled, the other prev:disabled, or even make them prev-enabled and prev-disabled.

Since "disabledness" is only a binary thing, and isn't the most utterly portable concept I don't think I'm going to let it interfere at the Component level. Well... perhaps after sleeping on it, perhaps a "DisabledDecorator" actually *is* the right approach. I'll think a bit more about the implications of this... right now I think the "enumerating options in the template" method is the best way.

Okey doke, it's in the template for now.