PDA

View Full Version : App Structure + Bug in MemoryReader



mindreframer
20 May 2007, 12:27 PM
Hello everybody, I have several issues, that maybe interesting for everybody....
1. The best way to structure your files
I've spent some time evaluating different approaches (all js in one file, several files responsible only for one area, etc....), but didn't like all of them.
When I write code, I like to hide the low-level work (and I mean there are a few levels you can go down) behind the real intention of the action/function. Ext is doing great work hiding all the crossbrowser issues from me and enabling to work with objects instead of fiddling with the DOM directly (for the most part). But I have no best practices for separation the different purposes of code...
So I thought, why not use MVC, but this time on the client. And I mean a complete, lightweight MVC structure without dependency of server.
What is the best way to develop a web app? You have to develop client + server architecture simultaneously, so you keep switching between js and server code. But if we agree on a contract defined by URL, and handle all the ajax communication through our model, we can develop the app with dummy data (arrays, objects, whatever you like, let's call them fixtures) that is loaded into the model and test the behaviour right there, tweak and tune, till we like it, and then just exchange the proxy for models to load the data from server. So, if you're in team (and who is not?), you can develop the frontend and leave the backend to your partner (or do it later yourself). What I like about this approach, is that you can test much better, since there are no timeouts and a running server to consider. You could even decide at runtime, what models to load, so unit-tests --> dummy model, production --> live model.
Automating and Unit-testing is also more feasible/less painful. Later you only have to test your "live" models, and feel good, because if something breaks, it must be in the model - layer.

These are only thoughts, it may look too simplistic, but it clears up your mind when you separate "movable" parts as much as you can. For now I've just copied the rails-style directory structure, which seems best of the breed.

Here is a prototype, it's very experimental and has sooo many memory leaks.
http://www.easy-comparison-kulist.com/staticjs/
(heavy load of js...)

2. In IE6 the model isn't loaded with data, dont know why... The proxy has the data set, and reader seems ok, but the store is still empty.
For now only profile does something, if FF it works, in Safari too, but not in IE :s I tried to the firebug lite(it's hidden behind the BorderLayout), then Ext.debug, the console is not very helpful (for objects it shows only [Object object], so after some research I found a variable dump utility, but it had infinite recursion problem (since child objects reference their parents and the loop is closed. I've just added a depth param to the function, so it would not dig too deep. When you click "Overview", the store for model "user" is displayed, the map and keys properties show the loaded data, but not in IE.

Could Jack please investigate this one, MemoryReader not working in a major browser kinda sucks....

I'd love to hear your comments about this idea!
Greets,
Roman

trbs
20 May 2007, 3:23 PM
These are only thoughts, it may look too simplistic, but it clears up your mind when you separate "movable" parts as much as you can. For now I've just copied the rails-style directory structure, which seems best of the breed.


IMHO The rails structure is just terrible; chipping all your files up in a gazillion little pieces without a clear and coherent structure is just bad. (granted I'm not a Rails fan)

Still in most full Ext apps where the entire application is just one page, there's little need to use such a fragmented directory structure.

Keep your Ext and your ServerSide technology separated !

Okey i understand that if you use something like Rails that isn't possible cause rails doesn't allow you too, but most server side technologies like Java and Python will allow you to cleanly separate Ext and server technologies. That way you only deal with data communication, authentication, sessions, etc on the server and the rest are only XML/JSON XHR (ajax) calls from the Ext application running on the client.

In the end all javascript on a page will just become one big block of code on the browser so it really does not matter much if there in a billion pieces or one big chunk. See how Ext deals with it itself. A file for each component/part in source and build that into one big mimified file for production.

Personally i have not have any problems with the MemoryReader, but i bet on it that it's a InternetExplorer problem and not a Ext one. Specially if it works on FF and Safari. IE is just a terrible bad ass browser that should just include decent errors and debugging or DIE. (guess the former will never happen, microsoft never done so in the past, so no change they'll do in the future) (and FYI: "Error in object line 1" is not a decent error message! :) )

p.s. guess you can guess that i'm not a big IE fan either B)

mindreframer
21 May 2007, 1:56 AM
The rails structure is just terrible; chipping all your files up in a gazillion little pieces without a clear and coherent structure is just bad.
Sure, this files will be concatenated and minified in production modus, it's just that I don't like files with too much code in one block.



Okey i understand that if you use something like Rails that isn't possible cause rails doesn't allow you too, but most server side technologies like Java and Python will allow you to cleanly separate Ext and server technologies. That way you only deal with data communication, authentication, sessions, etc on the server and the rest are only XML/JSON XHR (ajax) calls from the Ext application running on the client
Well, in Rails I just do the same, But for unit-testing I have to use some data in the database and asynchronous calls, which is not so good, if you have many tests (waiting for the server, only 2 requests at once, etc.). So not just keep the data for the client on client for the testing purposes?



Personally i have not have any problems with the MemoryReader, but i bet on it that it's a InternetExplorer problem and not a Ext one. Specially if it works on FF and Safari. IE is just a terrible bad ass browser that should just include decent errors and debugging or DIE.
This is a nice way to avoid responsibility, if something doesn't work, not my problem, yours! :))
But in the end I have to support IE, so guess I'll have to fix it myself. B) Will take some time, but it's possible.
trbs, thanks for your response!

mindreframer
21 May 2007, 3:50 AM
Hey, found the bug, had corrupt data in the array, the last element had a comma after it, FF and Safari just accepted it, but not IE
--->sometimes IE forces you to be a more careful programmer !:D

tryanDLS
21 May 2007, 11:18 AM
This is a nice way to avoid responsibility, if something doesn't work, not my problem, yours! :))
But in the end I have to support IE, so guess I'll have to fix it myself. B) Will take some time, but it's possible.
No one is avoiding responsibility by suggesting that it's your code that has a problem, rather than Ext. This is especially true if you say it works in FF and Safari, but not IE. As has been pointed out in numerous posts, when that happens, the first thing to check is a problem with your code.