Sometimes it is necessary to obtain a content of the portlet programmatically in hooked JSPs, but the APIs do not make it clear at all how to accomplish that.
There are some suggestions on the web on how this can be achieved, but the code seems to be somewhat complex, which makes it a problem to use in hooked JSPs.
For hooks there is a simpler method, but it relies on being executed in hooked JSPs by referring to some classes in portal-impl.jar:
When I started working with Liferay some things took me a while to figure out due to a certain difference in names used for Liferay features in user documentation and interface (Control Panel in particular) and names used internally in Java APIs, database tables etc. So I though a little table of correspondence might come handy for someone starting with Liferay or getting from user to developer level.
Let’s start with an extended example – Web Content, the base of Liferay CMS features.
It is actually mentioned on Liferay Wiki that some time ago Web Content was called Journal or something like this, but at a certain point all related portlets, control panel sections etc got renamed. Yet internally you will find no sings of “Web Content”.
The Java APIs for working with webcontent as well as DB tables are all still using old naming.
Web Content item is JournalArticle, Structure is JournalStructure and template is JournalTemplate.
To manipulate those you would use classes like JournalArticle(Local)ServiceUtil, JournalStructure(Local)ServiceUtil, JournalTemplate(Local)ServiceUtil, and to see them in database you’d have to look up tables also called “journalarticle”, “journalstructure” and “journaltemplate”.
So, let’s move on to our vocabulary: Continue reading
UPD: Apparently the sqlite BLOB export stuff is a popular request, and my article on how to do it here with Java program source code is just too complex for people that aren’t familiar with Java. So I’m going to do a better one soon, with more complete Java program, precompiled for anyone to use. Stay tuned.
Done! Check this post.
It seems JailBreak is not really necessary to get the files from SpeechTimerz
– you can use tools like DiskAid or iExplorer to get files from your iPhone apps, JailBreak is not necessary for that (which is good, because it seems iOS5 on iPhone4 isn’t properly jailbreakable still, and for 4s and iPad2 there’s even no “beta” jailbreak).
There is an iPhone app called SpeechTimerz that (among others) I use for ToastMasters public speaking club meetings to perform “timekeeper” role. Besides helping to track/indicate time this app also records audio during speech time, so technically by the end of the meeting all speeches are recorded and can be listened to from the iPhone. But there is no audio export feature in the app, so there is no way to get recordings anywhere.
Having a jailbroken iPhone I have access to all files on it, so I decided to dig in this apps files to see where does the audio go and check wether I could get it out. And I succeeded.
What I found out was that audio (in Apple Core Audio Format) is stored in SQLite database as BLOB (Binary Large OBject) field. So once I’ve got my hands on the file the task was to extract BLOB values from it. It turned out to be a bit harder than I thought.
The final touch was to batch-convert Apple CAF (Core Audio Format) to MP3, which also took me a bit of digging.
Liferay SEO capabilities seems to be surprisingly weak when it comes to URL management. Consider an example: you’re trying to build a webapp that will be doing some abstract searches over some search data sources, and present the results on one page.
You want page to have URL like http://<host>%5B:<port>%5D/section/subsection/search/<keyword>%5B?someParam=<value>%5D
Particular goals: URL can be generated by other website that knows nothing of our Liferay-based portal internals, and it (URL) should be nice and bookmarkable.
On the page you want to have some portlets, provided by different development teams/vendors, that would get the keyword and present results. The portlets should be independent since new ones can be added over time, and you want to be able to order development of several new portlets in parallel via several independent vendors. Thus every portlet on page should be able to obtain <keyword> and <value> passed in URL to page.