RSF Discussions Forum

Is this perhaps that case where you have some "rogue material" on the page, which is trying to render a URL as if from the templates directory of the app? Does your producer get as far as producing any tree?

No, I think that is looking a lot better. I think all you need to do is now make a return of "true" for entityExists in your provider upstairs (in the case the id is null) and you should be set to go.

What we think is that now you have the correct Spring context files in your webapp, you do not need the ReferenceParseeable capability, nor your custom EntityReference class. Try removing both of these, and report what happens - also, when/if you get the null pointer exception within AccessRegistrar, could you report what is the full URL and also the pathinfo for the incoming request?

Cheers,
A.

Implementing the EVPI should be sufficient. Did you create a bean for it in your Spring context?

When hosted as an "official" Sakai tool, the markup produced by the dynamic portion of a webapp lives in the "funny Sakai URL space" which begins with /tool-name/tool-id/LicenceDialog etc. So without concocting some sort of tool reference you will not succeed in addressing the content.

Yes, hosting this material within an EntityBroker "world" is a good way of busting out of the URL addressing limitations. You can host it as a "singleton entity" which does not require an entity ID, that is, it could appear at /direct/sakai-rights/LicenceDialog if you wanted.

OK.... this is a little clearer, but still not completely clear

RSF represents all the relevant information which is available in a URL by allowing the user to derive custom subclasses of ViewParameters (http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=ViewParameters), usually SimpleViewParameters - this takes care of one side of the equation.

It's not quite clear from your question, but it sounds like you are wanting to parameterise a family of renderers, that renders some different one of a set of custom components depending on type. In this case, you need to draw up a (Java) interface to a family of Producers, which will all render the appropriate segment of component subtree - http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=ComponentProducer

Awaiting any further question

Well, here you probably just want to write a bean which has the relevant mapping context injected into it, which it invokes methods on - that is, in this case, to "go against the flow" of IoC - there are examples in the central RSF mapping loader of how to do this for the various kinds of mappings -

https://source.caret.cam.ac.uk/rsf/projects/RSFUtil/trunk/src/uk/org/ponder/rsf/mappings/RSFMappingLoader.java

The answer to your general question (which is probably not quite what you wanted) is Spring's "MethodInvokingFactoryBean" -

http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/MethodInvokingFactoryBean.html

Cheers,
Boz.

Yes, there are a few ways round this - certainly "raw" encoding of some Java constructs (enums and other kinds of non-Pojos) will probably have unhelpful results with respect to a client-side as well as the implementation unhappiness that you mention. You could try adjusting your design, or else, forming a kind of sanitized "DTO" representation for serializing, perhaps simply using Maps or just reduced POJOs. And yes, you could also try a serialization library of your choice, such as JSONLib, and simply produce a ready-serialized String for the client-side, if your desired data needs too much conformance.

I will add the circular overflow bug for the upcoming release, thanks -

https://bugs.caret.cam.ac.uk/browse/RSF-137

Hi there Wilhelm - I believe the type Float.class is missing (through oversight) from RSF's GeneralLeafParser... to be honest, I had never quite understood why anyone might use the Java Float type since in most practical cases it results in no saving of either space or time. I will make sure that Float.class is added for the next release

https://bugs.caret.cam.ac.uk/browse/RSF-136

In the meantime, I suggest you switch to double and Double.class and see if this resolves the issue.

Cheers,
Boz.

Hi, I'm not quite clear about this question, and may need more detail from you. The way I understand it, you are trying to render components, housed in a UIBranchContainer, which should appear/activate dynamically as a result of Javascript behaviours. The easiest way to achieve this is, for example, to render the branches with a display:none CSS style, and then to pass the ID of the branch to an InitBlock

http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=InitBlock

which will execute some Javascript, perhaps targetting event handlers at the specific rendered branch. Note that the array argument to UIInitBlock.make can container raw components, such as the UIBranchContainer in question, which will be automatically be converted to the HTML id of the component which it will be rendered with, to allow it to be quickly located by Javascript.

Hopefully this answers your question, please get back with any more details.

The RSAC context currently only supports a basic subset of the Spring features, for performance reasons - there is a small chance that the <annotation-driven> notation may be supported, since we defer to standard Spring code for context file reading, but it is unlikely. It is a feature which is planned for the 0.8 release.

Hi, the function of UITooltipDecorator is simply to pass through to the browser's own rendering of title or alt attributes - for which HTML tags are not permitted. My suggestion is that you find a plugin for your favorite Javascript framework (say, jQuery

) that has the function of rendering rich text tooltips, render the text using UIVerbatim into a tag with CSS style of display:none, and then write a little Javascript to fish it out and display it in the tooltip.

Cheers,
Boz.

I suppose we could extend the template system with something like rsf:id="msgv=foo" which will represent an escaped message. I will note it for the next release...

Hi Stuart - two things... firstly, the "automatic 'for'" imputation should work whether the tag is being peered with a physical component (UIVerbatim) or a virtual one ("msg=foo"). So you should be able to keep your lighter syntax for label targets even if you have to escape the message by using a component... Yes, the use of markup in message files is somewhat "frowned upon" though it is supported, via the UIVerbatim(UIMessage) approach. Have you considered moving the font specifier <strong> outside the label? That would seem more natural.

Cheers,
A.

What is the exact name of the template that it says can't be resolved? There are quite a few examples of RSF-to-RSF helpers, I think for a start we had one in blogwow, but there is certainly one in the framework samples, for example sakai-entitybroker-test at https://source.sakaiproject.org/contrib/caret/entitybroker-test/trunk shows an example of an RSF app calling an RSF helper defined in a different tool, it uses the EntityBroker to expose the URLs which I recommend, that is it is what we called a "new-style" or AHAH-based helper.

I don't think there are any instances of an RSF tool invoking an "old-style helper" which is itself also written in RSF but this is probably not really advisable anyway. Even if you require to set up an "old-style helper" for some reason, I think it would be better to use the same views via the EB to also expose the function as a new-style helper and make this the preferred and advertised route, especially for new client code, which an RSF client would generally necessarily be...