30 Jul 2008
13 Oct 2008
Link to this post
Thanks for contributing, Gabe. Here are some additional thoughts that I've had on this... Sorry for the long post, but I'm more or less thinking outloud here, evaluating different approached and playing devil's advocate to myself...
So... I thought about creating a custom module for this sort of thing, but I guess I've liked the idea (so far), of keeping this relatively separate from Sitefinity. All of these web apps would serve very specific, relatively independent purposes, as opposed to, say, Images & Documents, Lists, or Generic Content, for example, which are there solely to aid in the website content management. In my case, on the other hand, these apps are more or less standalone--the only thing tying them together with Sitefinity is the need to maintain same look and feel with the rest of the site (which MAY very well mean that the best way to do this is, in fact, with Modules)...
I guess the way I think of Modules is: a central place to manage something that's [potentially] used in many different places on the website (Generic Content and Lists are excellent examples). But the little apps that I'm building will ONLY live on few, specific pages (including any admin pages), and will not necessarily need a "central" management location.
Now, speaking of admin pages... So far, that one app I built using the procedure described at the top of the thread, had a couple of admin pages--and this is where sitefinity came in handy, because I could protect the pages by NOT allowing annonymous access for them, and assign specific Role(s) to be the admins for this app (which is another requirement I forgot to mention originally).
But to build the admin page functionality itself, I had to build a couple of public controls, then drop them onto couple of new Sitemap pages. The controls didn't really have any public properties--everything was handled through code--because they weren't meant to be "flexible" for reusal on many different pages (so why build user-manageable properties). So, that's where I have a little concern with that approach--building public controls that are going to remain visible on the right-hand side of Sitefinity's list of usable controls, while in fact, they are only needed on a couple of specific pages. [Of course, one dirty way of solving that would be too comment out these controls from web.config, once they are placed on the Sitemap page itself--but seems silly...]
But then again, such is the case with many other out-of-the-box controls. For example, navigation-related controls are only used in a few templates, and that's it. They just sit there on the right, most of the time. Some others haven't been used at all. So maybe I shouldn't be concerned with running up the list of controls on the right???
I guess, so far, I see my options this way:
1. Build all functionality in public controls, then create new Sitemap pages and drop each control onto its respective page
- PROS: code is almost entirely self-contained and potentiallly reusable in a different environment, should that ever become important; relatively quick and easy to implement
- CONS: creation and addition of public controls that are really only used once
2. Build custom modules to manage each of the new web applications PLUS build any public controls (non-admin)
- PROS: public controls are kept to a minimum; Sitefinity API gets greater use (yay)
- CONS: harder to implement; addition of a 'central' management tool for something that only exists in one place; Sitefinity API gets greater use (too much investment into Sitefinity, perhaps???)
Anyways... those are some of my thoughts... I would appreciate any contributions to the discussion... So you see any other ways of doing this, in addition to those 2 approaches described so far?
One potential variation to #2 would be to build ONE SINGLE module to manage ALL future web applications (as oposed to, one module per custom app)... This thought came to me just now, so I haven't given it much more [thought]... but what about that? How difficult would it be to achieve something like that, considering the fact that the different web apps managed there would potentially be entirely different from each other? That would mean different options/screens to manage, different permissions for each app, etc.
Again, sory for the long post and all my ramblings here... Hopefully, others trying to do similar things will find this useful, too. ;-)