Development Strategy

I'm already using homegrown callbacks in my app, it's a great feature, and so I'm happy to see that Atlas is coming along so well.

My challenge is that I've got limited development resources (me and mine) and a limited window of opportunity to get my app to market. So I'm probably going to continue to test Atlas, and wait to put it into the app later in the development cycle, depending on how strong it looks at the time.

My question is, though, is there anything about the use of Atlas that I need to consider in terms of writing the app in the first place? More specifically, I recognize the "no screen flash" and other possible effects as seen by the user...that's why I started using callbacks to begin with. And I appreciate that there are probably ways to "optimize" the way the code is written to maximize the benefits of Atlas. However, I can't afford to do that now because of the risk that Atlas interfaces or behaviors will change at the last minute, and throw off my development schedule.

So the crux of the question is, is it safe to assume I can write my ASP.NET app without specific consideration of Atlas, and then drop Atlas elements (notably update panels) into it at the last minute, and for the most part "get away with it", i.e., not be stuck with a lot of changes required to make the app "Atlas" compatible?

Hope this makes sense, and would appreciate any guidance on it.

Thanks!

One advice is to make use of good HTML coding practice, such that when you integrate Atlas into the webpage, you don't get into a confusion yourself. Try to avoid using having too many layers of z-index. z-index:1 to z-index:3 should be enough for most scenarios.

I once working on a project, which requires me to atlacise a existing page with many bad HTML and CSS coding. The result was I end up re-writing the HTML elements and dragging in the ASP Controls one at a time as a attempt to clean up the attrocious HTML which the previous developer wrote. After the HTML is cleaned up, it took me just 10 minutes to atlacise the entire site.

hello.

hum...well, i'd say that with the updatepanel it's really easy (almost too easy, if there's such a thing as too easy) to transform an aspx page intro an atlas pages. if you want to use the full power of atlas, then you'll really need to decide on several things - ex.: how to update a record on a db? use a traditional page or use only client side HTML and perform the update of the record through a web service? you'll probably drop the updatepanels in many scenarios (specially if you're looking for a perfomance)

THanks Luis for sharing. Update panel actually affects performance? How much performance advantage would you get if you update directly via a webservice? Are there any advices when to use an update panel and when not to? It seems that most using the Atlas framework would make use of the UpdatePanel .

hello.

well, what i say is that if you're buildning a new app and want to use atlas, you probably should start by looking at the client side of atlas before using the updatepanel. i really think that the updatepanel is great when you just need to enable atlas on an existing aspx page. however, i also think that its usage is only justified when you are using a server side approach. and when you use it, you should also keep in mind that a partial postback results in the sending of all the fields maintained in the form (which might not be what you want when you need to perform a simple server side operation).

Thanks for inputs. The anectdotal experience reports and cautioning comments are great for providing "view ports" into this technical area.

I'm concluding that waiting to add update panels to well-formed pages is a relatively low risk approach. I'm sure I'll be testing Atlas along the way, as well.

Agradecimento!