View Full Version : starting new project in ExtJs, please help me with some questions

1 Sep 2010, 12:44 AM
Hi everyone,

I am starting an project in ExtJs for school and would like some pointers on various questions if you would be so kind. Usually I am an hands-on guy, but in this case some digging should be done.

Earlier I have already worked with ExtJs (small projects), there is some knowledge, although it has been one year ago.

- The project will be an portal/dashboard with panels for each grid, form, wizard etc. Is it wise to use modular, standalone panels?
- I'd like each written word to be localized, are there any pointers to achieve this?
- Working with data in an multi user enviroment can be prone to polution, is it possible to push data changes to the clients currently viewing grids/forms? (n-tier enviroment)
- What is the best approach to save the current layout of the portal/dashboard, and also layout/settings of an grid (column width, shown columns etc)?

Many thanks in advance for any advice you can give me!

1 Sep 2010, 10:55 AM
Have you see the portal demo on the Sencha samples site?
Go to products->extjs, then click "layout managers" in the demo-menu.
(I cannot post links cuz then this will be moderated.)
Then scroll the demo-list-window down a bit to the end and you'll see "portal demo".

The demo is pretty nifty -- uses a column model for the dashboard "slots".. standard panels are used for the "modules".

Localization --

a) put all strings in a separate file called project-name-en.js

The contents is something like...
PROJ.Constants = {
SOME_STRING = "this string can be localized, your name is {0} and the time is {1}";

b) Then when you want to use the string, and specify the values for {0} and {1}....

var localizedString = String.format(PROJ.Constants.SOME_STRING, username, time);

c) To support additional languages, create another string file, e.g. project-name-fr.js, and include those localized files.

d) Finally in the html, include the js file based on locale. E.g. in java frameworks the browser has a variable indicating locale, which can be used as part of the .js filename to select the correct language file.

Afaik, extjs doesnt directly support push. So, I suspect you'll need a different framework for this; once you get the data you can load it into grids, etc, using an ArrayStore and reload(); you'll likely need dig into the docs for this.

As for saving layout, module settings, positions, etc... I'm doing a similar thing, and just saving asynchronously to the server whenever there is a client side change. Eg. when a module is moved (dropped) there is an event, and the event sends a message to the server "saving" the position without any intervention from the user. I've seen some dashboard UIs that have an "edit mode", such that the current state is "client only" (in memory); there's an explicit "save" command which then sends all the positions, attributes, changes, etc to the server for persistence.

hope this helps...


p.s. I'd like to also hear about production-quality commercial-use-allowed server-side push client/server frameworks.

1 Sep 2010, 11:11 AM
Look in the examples at the desktop and also at the portal example.

I think the desktop is more flexible.

then there is a tutoral on internationalization, you can also find several threads on this.
my last project we did a desktop that was internationalized and it worked fine.

1 Sep 2010, 12:39 PM
Much appreciated on the extensive post response!

In regards to not being able to push events to the clients. I think i will solve this with an record lock flag as soon as someone is changing data. Albeit not being the best solution this should avoid the major conflicts.

Reloading data on grids or views every few secs is not something I would vote in favor of, it just doesnt sound right. Hopefully someone will have some kind of way to push events.

Thinking out load here: I could make an reload which checks the current visible record IDs from an grid with loaded timestamp against an changed record ID with timestamp. So it would only reload the visible record when required.

This is not fail save, as the table with changed records should not be too large. Meaning older timestamps should be removed quite quickly. Just rambling on here, I could save the clients last load action timestamp and delete anything older than that. Will do some testing in respect to this.

Any comments? Is it even worth it to make the grids and views data change aware?

1 Sep 2010, 4:37 PM
Every-few-second refresh.. no, I'd not do that. Our stuff does like a 60 second refresh. And there are typically just 10s of users.
Also, I wouldnt want to be doing an extensive db query for _every_ client... In a similar project I had a single db query prep the data into an xml file, and the xml file was retrieved from dashboard widgets that were graphing the data. Hence the work on the server side was one query for all clients plus just a simple file download for each client.

It really depends on the application... if it is something like chat (or realtime stats) then you will need some sort of push.
Recently I was looking at the node.js stuff... good for apps like swarmation dot com.

One concern about the record-lock approach... if a client locks the record, but then never unlocks it - e.g. network connection goes down etc... you'll also need to handle the lock-timeout problem.

Depends on the app, but for when we want to "warn" users that the "data is stale", we use optimistic locking..
The client has a timestamp token for the current data state. When the client updates the state, the update is done with a "where" clause that includes "token=<current timestamp>". If the DB returns "zero records updated", then we know the data is stale, and that client gets a refresh with the current data... additionally, the client can tell the user that the data was stale - changes no saved.

Again, depending on the app.. you could have an "currently being updated by user X" that is merely additional state and _can_ be overriden by another client. Then include an explicit "save" action that clears the state... ie sets it to "not being updated".
I suppose that's like record locking but its not an explicit DB lock. The TWIKI that I use has this behavior -- page is locked for editing, but anyone can break-the-lock.

It really depends on the data size and number of users... if it is a small scale app, I'd keep it simple and just do a refresh.
If we're talking 1000s of clients and a decent amount of data (? several 10k per refresh?) than I'd consider optimizing.
I'd suggest getting something working to explore the technology, then optimize.


p.s. I like the portal over the desktop example cuz of the snap-to-grid functionality.