On 11 March 2010 09:15, cweagans <[email protected]> wrote: > I'm afraid I can't go into detail on what functionality that is not > available, however I can say that handling the output in this way > would provide the functionality we need. >
Makes it hard to assess your proposal, as I said it has the potential to cause major disruption during its development, or Stuart has to support two versions for some period of time (eg Python 2.6 and 3). As an asciidoc user I need to understand the payoff for the risks, but you are not giving me anything so far. I have worked in classified situations in the past and it is always possible to talk about general capability without giving away what you want to use it for. Just invent a simple use-case, and if its SO specific that you can't, then how useful will it be to the asciidoc community? Also if you need to be able to release the resulting code and you are going to have to talk about it in its documentation. I'm wary of "trust me I'm a programmer", because I am one :-) On the other hand more general solutions are sometimes useful, obviously you think you need it :-) so why not make it just another another backend. That way the current ones don't get disrupted (too much). I would also urge making the config file format as similar to the current format as possible, just with Python to run instead of text to inject into the output. > > Re arbitrary python: The only python that would be executed is the > python that's included by the output engine author. So how do I configure it when one of my documents needs different behaviour? I can't change the system files since that would change it for all documents. The current asciidoc approach uses a cascading hierarchy of configuration files that allows this. But a cascading set of Python files allows malicious code injection. I'm not trying to over emphasise this, but it is a risk. > This is a good > thing because asciidoc would no longer be limited to building a single > file from one single input. You could split the document up into > multiple HTML documents (without a2x) or you could automatically post > it to a website. > I've always wanted to accidentally automatically post NDA things to a website :-) see security above. Since you have to write the Python anyway, to put in the configure file, better to do it via a python script that runs asciidoc first and then does the extra things. That way a the asciidoc command doesn't do something embarrassing that you didn't expect :-( > Anyways, the system I've proposed is heavily based on the theme system > from Drupal. > Well, just because its widely used doesn't mean its good, I give you the Unix command line as an example, hehe :-) Cheers Lex > > On Mar 10, 2:59 pm, Lex Trotman <[email protected]> wrote: > > On 10 March 2010 11:38, cweagans <[email protected]> wrote: > > > > > > > > > Below is a paste of a conversation I had with Stuart via email. Any > > > input on this topic would be appreciated, as my company is wanting to > > > move forward on this. If the Asciidoc community is interested, we'll > > > build it on Asciidoc. Else, we'll go with another solution that > > > supports what we need (we want to contribute to an open source > > > project, hence my post. If the contribution just doesn't really fit > > > any projects, we'll either create our own or use Open Office or > > > something) > > > > > +-------------------------------------------------------- > > > from: [email protected] > > > to: [email protected] > > > date: March 8, 2010 > > > +-------------------------------------------------------- > > > Hi Stuart, > > > > > First off, I'd like to thank you for all the work you've put into > > > asciidoc. We're using it internally for documentation and customer > > > manuals and such, and it's working really well! > > > > > We've been having some difficulty with asciidoc, in that it's > > > difficult to do some of the things that we'd like to do (sorry for the > > > vagueness...I'm not really allowed to say too much about our > > > documentation, due to a super-strict NDA). I'm a programmer and I'd > > > like to implement our needed features, but I don't want to put a bunch > > > of time into it if it won't be accepted as a contribution to asciidoc. > > > > > So, my question is, how would you feel about a major rewrite of how > > > asciidoc outputs formatted data? Existing documents will be > > > unaffected, as the modifications would only affect the output logic. > > > These changes would allow for more output formats, as well as the > > > ability for end-users to tweak how asciidoc outputs data (for example, > > > it would be a very very trivial matter to make asciidoc output <h1 > > > class="class1 class2 class3" id="header_123"> rather than just <h1>. > > > > > Essentially, I'm talking about building an easily extensible output > > > layer for asciidoc. > > > > > Interested? > > > > > -Cameron Eagans > > > > > +-------------------------------------------------------- > > > from: [email protected] > > > to: [email protected] > > > date: March 8, 2010 > > > +-------------------------------------------------------- > > > Hi Cameron, > > > > > You will need to be a bit more specific, some examples (input and > > > output) would be nice, any text is fine, no need to include any NDA > > > related stuff. Also the rationale and the advantages of you proposed > > > changes would be good. > > > > > I suggest that you post it to the AsciiDoc discussion list (http:// > > > groups.google.com/group/asciidoc) to get input from other users. > > > > > Cheers, Stuart > > > > > +-------------------------------------------------------- > > > from: [email protected] > > > to: [email protected] > > > date: March 8, 2010 > > > +-------------------------------------------------------- > > > > > Basically, what I'd like to do is this (I'll use the XHTML output > > > format for my examples): > > > > > There is a set of entities that asciidoc supports for rendering. A non- > > > exhaustive list: headers (1 through 6), bold, italic, underline, > > > normal text, and code listings. > > > > > Every output document has a set of entities that it requires. In my > > > vision for this implementation, you'd have a directory for every > > > output format that contains template files for each asciidoc supported > > > entity. > > > > > /home/cweagans/asciidoc/output/xhtml: > > > document.tpl > > > h1.tpl > > > h2.tpl > > > h3.tpl > > > h4.tpl > > > h5.tpl > > > h6.tpl > > > bold.tpl > > > italic.tpl > > > underline.tpl > > > text.tpl > > > code_listing.tpl > > > xhtml.conf > > > > > Each .tpl file is simply a python script that prints the appropriate > > > markup (or uses a python library to generate PDFs or to generate ODT > > > or....you get the idea). > > > > > document.tpl might contain: > > > > > print """ > > > <html> > > > <head> > > > <title>%(title)s</title> > > > </head> > > > <body class='%(body_classes)s''> > > > %(content)s > > > </body> > > > </html> > > > """ % variables > > > > > variables would be created when the file is loaded and populated with > > > the needed information to build the document. > > > > > Smaller entities are trivial: > > > > > h1.tpl might contain: > > > > > print """ > > > <h1>%(content)s</h1> > > > """ % variables > > > > > The .conf file might contain some information about what order to load > > > the entities, or maybe a reference to a pre-build or post-build script > > > that would get executed before or after the initial compile on the > > > document (for example, a .odt post-build script might write all the > > > needed files and compress them into the archive format needed for > > > opendocument) > > > > > Since all of the entity templates would be standard python, there's no > > > reason why asciidoc couldn't support, for example, .odt output or even > > > (if you are feeling -really- daring) voice files or microsoft word > > > documents. > > > > > I haven't fully fleshed out the idea because I haven't actually > > > started implementation, but that's the basic idea. > > > > > What do you think? > > > > > -Cameron > > > > Hi Cameron, > > > > I'm all for highly configurable systems, but I'm also wary of significant > > re-implementations that may change default behaviour, add bugs and reduce > > default functionality (KDE anyone? :-). > > > > Can you explain what functionality is gained over the existing > configuration > > files system? Especially what you need that is not available, or can't > be > > added to the current system? > > > > Also I would note that executing arbitrary Python from files is a HUGE > > security risk, it could mail your NDA docs to me each time you asciidoc > them > > :-) > > > > Cheers > > Lex > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "asciidoc" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<asciidoc%[email protected]> > <asciidoc%[email protected]<asciidoc%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/asciidoc?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<asciidoc%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/asciidoc?hl=en. > > -- You received this message because you are subscribed to the Google Groups "asciidoc" 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/asciidoc?hl=en.
