I didn't know until I read the free ebook "Linux 101 Hacks.
(It lets you change between the two last directories.)
Oh, -the book is really free. At least I found the password at the web site without registering my email address.
I didn't know until I read the free ebook "Linux 101 Hacks.
(It lets you change between the two last directories.)
Oh, -the book is really free. At least I found the password at the web site without registering my email address.
Found a Firefox add on for symfony development while I was downloading firebug today. Haven't tried it yet, but might give it a try next time I'm working on one a symfony project.
(This post is heavily updated and is now just a list of links.)
You may like this articles or not, but, after having used Windows since 1995, I feel qualified to say that these post are not just funny, they are also informational and most of all they represent a refreshing change. :)
Also, if you know more articles like these, please add them below. Also add them to delicious with the keywords getthefacts windows whywindowsisnotready, vote them up digg or whatever you want and help spread the word :)
Do you have a good one? Leave a comment!
Another post about the JSF 1.2 upgrade.
Short description of the problem:
We had hacked together a custom pick list from before. After upgrading to newest JSF and newest RichFaces, we could use a standard pick list, except that the standard pickList didn't support any means of showing details about the selected item.
We could of course tried to subclass the RichFaces pick list component, but then we would be stuck with maintaining it. So instead we decided to just throw in a quick jQuery script. Of course, it would also be a good opportunity to learn a little more jQuery. (Yes, I've just started learning jQuery, so if you think you've got a better way to solve the problem, please leave a comment.)
<ui:define name="perPageJavaScript">
<script>
jQuery(document).ready(function(){
jQuery(".rich-picklist-source-cell").click(function () {
updateFooBar(jQuery(this).text());
});
});</script>
</ui:define>
<a4j:form>
<a4j:jsFunction name="updateFooBar"
reRender="fooBarTbl,fooBarBazTbl">
<a4j:actionparam name="param1"
assignTo="#{fooBarBean.selectedFoo}" />
</a4j:jsFunction>
</a4j:form>
the perPageJavaScript is just a way to insert a custom JavaScript into the header of one particular page.
Hope this helps someone. I guess I'm not the only one who needs this construct.
Had forgotten to remove some pictures I used early in development of my online pomodoro timer. When I removed then, the size decreased from >1 MB to less than 100 KB :)
Hope this will reduce loading times significantly. If not, there is a feedback form on the third tab on the page. Feel free to report bugs or add feature suggestions.
I've just upgraded a project from JSF 1.1 (MyFaces) with tomahawk to JSF 1.2 (Mojarra) with Facelets. Halfway through the process I realized it would be worth sharing, since I would have appreciated if somebody else had done that before me. (There is a description about how to make a new project with JSF 1.2 on http://forums.sun.com/thread.jspa?threadID=5156242, but I wanted to upgrade an old project.)
Because facelets are xml documents you need to change && in your expression language statements to && (I found the tip here: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=001835.)
Update 2008-12-23: If you're smart and read the documentation, you might also find out that you can just write and instead of both && and &&.
Also remember that xml comments are written as <!-- --> instead of <%-- --%>
While I appreciate the effort that people has put into MyFaces/tomahawk, it also became a major hurdle in the process of upgrading the application. The reason is that it took very long time before the developers announced a JSF 1.2 compatible version, and by that time, I was already decided to get rid of that taglib.
We mainly used to use the tomahawk library for 4 different things:
<t:updateActionListener value="#{fooBean.bar}" property="#{bazBean.bar}" /> can now be substituted with <f:setPropertyActionListener value="#{fooBean.bar}" target="#{bazBean.bar}" /> in the standard f: taglib.
t:dataList can be substituted with rich:dataList
The components in the tomahawk taglib has an attribute called forceId which overrides JSF's id generation, allowing you to specify the precise id you want for a tag.
There's no such things as a forceId attribute in any of the other taglibs we use, but luckily, with facelets you can now use plain html tags if that is what you want. Also, much of the reason for using forceId was for selenium testing. Later on, I learned that we could use xPaths with selenium to pin down a page element without resorting to the id. (If you decide to try, there is at least two different Firefox plugins that you can use to find the xpaths, and at least one of them is useable, I just can't remember the name.
The last reason for using tomahawk was either the sortable table or the fileUpload component. Luckily, both are easily available in the rich taglib.
At least not i mojarra. Here's my changes:
- public SelectItem[] getFooBarOptionList() {
+ public List getFooBarOptionList() {
List optionList = new ArrayList(FooBazFooBarEnum.values().length);
for (FooBazFooBarEnum fooBar : FooBazFooBarEnum.values()) {
optionList.add( new SelectItem(fooBar.getValue(), fooBar.getValue()));
}
- return optionList.toArray(new SelectItem[optionList.size()]);
+ return optionList;
}
<managed-property>
- <property-name>fooBarOptionList</property-name>
- <property-class>
- javax.faces.model.SelectItem[]
- </property-class>
- <value>#{fooBazDetailFilterBean.fooBarOptionList}</value>
- </managed-property>
<managed-property>
+ <property-name>fooBarOptionList</property-name>
+ <property-class>java.util.List</property-class>
+ <value>#{fooBazDetailFilterBean.fooBarOptionList}</value>
+ </managed-property>
Here's some code to fetch whatever managed bean you need without injection. I don't suggest you should do anything like this, but if you have already done it, and need to upgrade to JSF 1.2, here is how:
From:
public static Object getBean(String beanName) {
return getContext().getApplication().getVariableResolver().resolveVariable(getContext(), beanName);
}
To:
public static Object getBean(String beanName) {
return getContext().getApplication().getELResolver().getValue(getContext().getELContext(), null, beanName);
}
Remember: use with caution, as the result may be hard to unit test.