fre, 06,.05.2005 kl. 17.23 +0200, skrev Marcin Soltysiak: > From: "Henri Bergius" <[EMAIL PROTECTED]> > > Tarjei Huse wrote: > >> 2. Make a new "base content" component that handles topics that have noe > >> defined component (for migration of existing data). > > > > Or how about making a content migration wizard based on my nnb2midcom > > script? > > http://www.nehmer.net/~bergie/nnb2midcom.txt > > > > Especially if people are used Tony's index article enabled Aegir > > Sample Site, the data format is very close and you can keep > > both MidCOMized and the old Aegir-style site running side-by-side. > > How about sites driven by proprietary applications? I got dozens such sites > from pre-MidCOM epoch.
My plan is that this issue should be tackled in not one but a few ways: 1. Use OB as bergie suggested This is the first stage, lets the app work as it has always done. 2. Have a simple php midcom. I.e. a midcom that lets a new developer create a simple page in midcom (say a form) and display it without knowing any midcom internals. This is for that quick-and-ready app you needed yesterday. Also it lets new people start a bit slowly. (I'm not sure if I can a difference between this one and number 1 - but it is there) . 3. Develop good MidComs for the most used situations: -> A midcom that better handles taviewer/newsticker situations w/o resorting to stylehacks. -> a quickform midcom for that form you just need (it's comming allong). That should cover most situations. Tarjei > > Solt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Tarjei Huse <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
