|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
I got stuck a bit today. It took me getting out of the programming tools and back to paper to get myself unstuck. By diving into code too soon, I'd painted myself into a corner without understanding the nature of the problem. It took more thought and less code to solve the riddle.
Now that I've got some really powerful tools to play with, I'm having to think about things I never did before. For example, where does an application's data begin? A user hits my XPage and that user is new. There's no profile. Do I pre-create one for them to act as a jumping off point? That seems to be the standard out there. The minute you arrive at any site where you'll be creating data, you're asked to sign up and sign in. They do that because they want to have something as a "ROOT" level on which to base all that data you generate.
I'm a big fan of putting the user profile outside the application in its own database, easily keyed on the userid --Store only global stuff there. Things that won't change from application to application. That gives you a system wide platform on which to build your various application specific data.
When you're stuck, give more thought to architecture, and less to the act of coding.
Please wait while your document is saved.
wouldn't be in a traditional app? I'm not arguing with your point, but I think
you've taken a logic leap that some of your readers might not follow.
The interesting thing, to me, about what XPages bring isn't so much the "what"
as the "why" - why do I do something a particular way in a tool where I have a
zillion options, and why does this tool change the way I think of the app to
begin with. Note to self: remind IBM to answer those questions before they go
Gold with this...