<br><br><div class="gmail_quote">2010/4/24 Christophe Combelles <span dir="ltr"><<a href="mailto:ccomb@free.fr">ccomb@free.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ilshad Khabibullin a écrit :<br>
> Hi Christophe,<br>
><br>
> 2010/4/23 Christophe Combelles <<a href="mailto:ccomb@free.fr">ccomb@free.fr</a> <mailto:<a href="mailto:ccomb@free.fr">ccomb@free.fr</a>>><br>
<div class="im">><br>
> hi,<br>
><br>
> what about bringing back zope.app.apidoc ? It is a very useful tool<br>
> during<br>
> development and it allows to dynamically add other namespaces such<br>
> as z3c, zc,<br>
> and even the project packages. There is probably a few changes to do<br>
> in apidoc<br>
> registrations. A very good thing would then be to move it to<br>
> zope.apidoc later.<br>
><br>
><br>
> We need this, it is powerfull tool, and developer can include apidoc in<br>
> any moment. But I think, developer needs these features mostly in<br>
> _some_context_, i.e. to inspect components "on fly", not just to see<br>
> docs. The more so the documentation should be moved out the doctests in<br>
> future, yes? In this case displaying them via wsgi-server is not the<br>
> best idea... there are editors, Sphinx, etc. Summary, lets' divide:<br>
><br>
> 1) Need to see dynamic data - i.e. components, relations between them.<br>
> 2) Need to see static documentation.<br>
><br>
> For dynamic data - inspect registry. Sometimes, we dive into exist zope3<br>
> project and "I am feeling that somewhere registered adapter, but where<br>
> he, is the devil...".<br>
<br>
<br>
</div>I agree we need both static doc and dynamic doc.<br>
<br>
Because when the app can't start, there is no apidoc... The<br>
<a href="http://apidoc.zope.org" target="_blank">http://apidoc.zope.org</a> already is a static doc. Is there a way to include the<br>
static generation tool in a project?<br>
<div class="im"><br>
<br>
><br>
> There is a way to enable it only in devmode with<br>
> zcml:condition="have devmode".<br>
> I think we can provide at least two buildout files for this purpose,<br>
> one for<br>
> production, one for development using devmode and apidoc. It can be<br>
> easily done<br>
> with the templating system currently included.<br>
><br>
><br>
> BlueBream is server-side software. When I create project, I need deploy<br>
> this project on my sandbox and on server, in any case. So, I spend time<br>
> for production-server-boilerplates, copy-past from older projects :)<br>
><br>
> Then we need decide:<br>
> 1) We provide the simple and policy-free template<br>
> 2) Or we provide powerful template for server-side projects. It can be<br>
> relatively polcy-free, I think.<br>
<br>
<br>
</div>I don't know what is the best. We need to ease both development and production,<br>
but we must not bring too much complexity, nor large configuration files.<br></blockquote><div><br>I mean both, yes, I.e. at least 2 - development and production. Which difference usual? In my practice, bootstrap user, includes to mail configurations (or just mailer directive directly in size.zcml) - at least in each project. Like to see more experience from other developers to make resolution.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So that beginners shouldn't be frightened. It *must* remain easy to understand<br>
and easy to explain.<br>
We should probably do some tests in sandbox branches.<br>
<div class="im"><br></div></blockquote><div> </div>Difficult to find a balance - so let's define the goals.<div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
><br>
><br>
><br>
> If there is a way to do this without needing the templating, I would<br>
> be +1 to<br>
> remove the templating.<br>
><br>
><br>
> alternative - zcml in .cfg files - here is example:<br>
> <a href="http://paste.lisp.org/+23S0" target="_blank">http://paste.lisp.org/+23S0</a><br>
><br>
> But it seems, templates is better... I'm not sure exact... Personally<br>
> for me, these big and mess buildout.cfg files is bad. And system<br>
> administrators not liked this, I know (because we need provide<br>
> instructions how to edit these files, remove or add bootstrap manager<br>
> and etc.)<br>
<br>
</div>I'm also *strongly* against including ZCML (and zope.conf) in the buildout. It<br>
make me think of the desperately giant plone buildouts I regularly see. It's<br>
unreadable, and most people are confused.<br>
<div class="im"><br>
<br>
><br>
><br>
> Same question for zope.app.onlinehelp and zope.app.preference ?<br>
> _______________________________________________<br>
> bluebream mailing list<br>
</div>> <a href="mailto:bluebream@zope.org">bluebream@zope.org</a> <mailto:<a href="mailto:bluebream@zope.org">bluebream@zope.org</a>><br>
<div><div></div><div class="h5">> <a href="https://mail.zope.org/mailman/listinfo/bluebream" target="_blank">https://mail.zope.org/mailman/listinfo/bluebream</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Ilshad R. Khabibullin<br>
> <a href="http://astoon.zwiki.org" target="_blank">http://astoon.zwiki.org</a><br>
> +7 922 600 56 06<br>
<br>
_______________________________________________<br>
bluebream mailing list<br>
<a href="mailto:bluebream@zope.org">bluebream@zope.org</a><br>
<a href="https://mail.zope.org/mailman/listinfo/bluebream" target="_blank">https://mail.zope.org/mailman/listinfo/bluebream</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ilshad R. Khabibullin<br><a href="http://astoon.zwiki.org">http://astoon.zwiki.org</a><br>+7 922 600 56 06<br>