On Nov 13, 2006, at 10:19 PM, Karl Guertin wrote:
> On 11/13/06, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Why don't we start out with SO-only documents. Then we can
>> identity the
>> portions that vary between DB platforms and develop "plug-in"
>> replacements for the SO bits.
>
> Sure, I'm willing to do this. I use both fairly heavily and for
> everything except object definition, the differences are trivial. One
> issue (and one of the reasons I'm holding off) is what form official
> SA support will take.
I haven't had a chance to really look at TurboEntity yet (and I know
there's more going on in that arena right now). My intention is for
TG to support both the Data Mapper pattern style ("standard
SQLAlchemy") and the Active Record pattern (ActiveMapper/TurboEntity)
simultaneously. It currently does this with ActiveMapper.
Particularly with the work that's going on to create a better Active
Record style layer, I think that using a layer like that will make
people happiest for many applications (particularly brand new
applications that aren't dealing with legacy database designs). I
would expect the docs to follow suit, generally using the Active
Record layer, but probably with a doc that discusses "standard
SQLAlchemy".
>> We could use a web framework (like TurboGears!) to integrate this
>> so one
>> could just select one's platform either in the URLs or as a session
>> variable value.
>
> I think the simplest solution is to write a docutils plugin that will
> take a series of alternates, display the first, and set the remainder
> to ``style="display:none"``. One possibility is to cheat by something
> like a general admonition with a custom admonition type and do all of
> the hiding in javascript.
>
> As for the selecting a preferred platform, that's simple javascript
> cookies.
>
> I'll probably implement this after I finish off the docs I feel are
> necessary for 1.0 (including API docs and decent docstring coverage).
> If someone wants to do it in the meantime, we're always up for
> contributions.
Here's another alternative: We could start building parallel docs in
the 1.1 area. I suspect that the biggest changes for users to deal
with will be those component changes, so there wouldn't have to be a
huge difference for many of the docs. It's not a perfect solution
(and probably not as good as Steve's suggestion and Karl's
implementation idea), but it's one that can be done without any
additional infrastructure. That said, a little bit of JS and CSS is
not a lot of infrastructure :) I thought I'd mention this, because
we'll want to make 1.1 docs as it's developed so that we don't have a
giant doc-lag-time at the end of the release cycle.
Kevin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
