Since I work as a web developer, I have noticed that basic engineering principles are not always being consistently applied to web applications design, architecture and development. I am talking about modularity, black-box design, documentation and quality assurance, among others.
This is a small collection of Java classes to provide a simple profiling functionality: include it into your application to register the time consumption of your function calls. It may come in handy where a particularly slow module has been spotted and there is no need for a more complex profiling system
Besides of a time line of the application execution, it creates an histogram to present where your application spends more resources and what the most called functions are.
Configuring Lotus Domino WebDAV for third-party tools development has had us struggling a few days until we succeeded on make it actually work. There is a good article here that explains the basis of allowing WebDAV into your server.
However, that’s not all of it. The method above will never work unless you set the right permissions for the user ‘anonymous’ to the database you want to access. That’s it: individual database access must be configured, as it is explained here. The official reference can be also of help, although a bit outdated.
Even then, we had a lot of trouble working with the WebDAV enabled browsing. Under Windows 7 with Explorer, it seemed not allow any kind of file copying – but it allowed to create folders and files by right clicking directly on the directory, though. Also, we were having problems on MAC OS Finder in form of random write errors. All this stuff was pretty confusing and unclear on every forum and blog that we visited for help.
I have been struggling for a while to find a way to dynamically load CSS resources in a coherent and reliable manner. As I am working with dojo on my current project, I started with using its event connectors for a classical approach: creating a DOM link element with the desired CSS resource and adding it to the document’s header programmatically.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
I write this post claiming to heavens that you (as a web developer figuring out whether to use or not iframes) will read and follow my advice. Not only for me, nor for you, but for a better world.
Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.
And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app: