Archive for July, 2008

Ext JS: Combine 2 services output into a single grid

July 28, 2008 at 8:03 pm · Filed under Technology, howto ·Tagged ,

#26 in this Ext JS FAQ inspired me on how to combine 2 services output into a single grid. The concept was all that I needed. I ended with my own implementation following the same concept. For my practical use, I created 3 stores. The 3rd one held aggregate output from the first 2 stores. This was easier for me to add an extra column that doesn’t exist in the first two. I followed the same concept as the one presented in the response for Q&A #26: register a function that listened on ‘load’ event from the source store. In the function, I first removed old records originated from the same store before adding the new data from the source stores. This was probably un-necessary. I just wanted to makes sure that there wasn’t duplicates. Before I added the new data into the target store for the grid panel, I had updated each record for my needs. I had to use the records array generated from the source store and pass the modified version to the target store instead of creating my own records.

I am happy with the results and thanks to the authors of the FAQ. It helped.

Leave a Comment

JavaScript annoyance on Safari

July 25, 2008 at 4:54 pm · Filed under Technology ·Tagged , , ,

I encountered a JavaScript issue on Safari while the same script works fine on Firefox and IE. Based on what I could find, WebKit appears to be the only bundle that contains a JavaScript debugger. Since WebKit is the open source web browser engine that Safari uses, it essentially is the bleeding edge of what Safari might pick-up later. This can be a good thing that if a fix goes into WebKit now, you can safely expect Safari will pick it up sometime in the future. At the same time, before Safari pick up the fix, you are essentially at a crippled state. I hope Safari has a faster release cycle.

Comments (3)

Notes about PersistJS

July 15, 2008 at 5:04 pm · Filed under Reviews, Technology, links ·Tagged , , , ,

After I tried to use PersistJS, I am impressed. Then people are asking me to write-up my findings. So, here are my notes about PersistJS:

The first recommended reading is Why This is Awesome section. It makes a good case why you should use PersistJS. One interesting aspect of PersistJS is explained in its README: “Each backend is wrapped by PersistJS and exploses the exact same interface, which means you don’t have to know or care which backend is being used.” This means that you are not limited by a single technology and this enables you to adopt to a different storage easily. This statement might leave you with the question about which one does PersistJS choose? To answer this question, I found the order which PersistJS chooses a back-end store:

  1. gears
  2. localstorage
  3. whatwg_db
  4. globalstorage
  5. flash
  6. ie
  7. cookie

In my first implementation that uses PersistJS, I did not load extras/gears_init.js or extras/swfobject.js, this means that google gears and flash back-end stores are not enabled in my use of PerisstJS. With this setup, localstorage becomes the first one that persist JS attempt to store data.

PersistJS uses HTML 5 localStorage DOM attribute to implement its localstorage storage. HTML 5 is a new specification in draft state now. localStorage is one of the two storage mechanisms introduced, which “is designed for storage that spans multiple windows, and lasts beyond the current session.” The the storage format that HTML 5 exposes are key/value pairs. Both keys and values have to be strings. For further reading, see specification draft.

If you are an Ext JS user, you can use PersistStateProvider to persist UI state and application data.

Comments (1)

Setting up printer sharing using Samba

July 3, 2008 at 8:59 am · Filed under Technology, howto ·Tagged , , ,

I followed the instructions on this page to share a printer on my local network. The part that was not clear to me initially was “what is the shared printer name?”.

Then I found out that the shared printer name was the same as the local printer name configured in CUPS. This probably caused by load printers = yes option in smb.conf file. After I set the shared printer name on the client side, printing across the local network works!

Leave a Comment