[Trac] Is it possible to use different versions of a plugin in multi-project environment?

[Sneha]

Hi All,

We are working on multi-project Trac environment. we have modified a
plugin to suit a project's requirement. Is it possible to install this
modified version of the plugin for a certain project and use the
default (unmodified) version of the same plugin in all other?

We are using easy-install --always-unzip  command to install plugins
for all projects.

Thanks,
Sneha
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Is it possible to use different versions of a plugin in multi-project environment?

[Christian Boos]

Sneha wrote:
 Hi All,

 We are working on multi-project Trac environment. we have modified a
 plugin to suit a project's requirement. Is it possible to install this
 modified version of the plugin for a certain project and use the
 default (unmodified) version of the same plugin in all other?
   

Not unless the modified plugin also uses a modified package name (i.e. 
if the source lived in tracpluginsomething/, rename that folder to 
tracpluginmysomething/ and update the setup.py file accordingly).
Or refactor the change you did so that it only gets activated when some 
option is selected in trac.ini, and turn this on/off in the different 
environments.

Hope this helps!

-- Christian

 We are using easy-install --always-unzip  command to install plugins
 for all projects.

 Thanks,
 Sneha
 


   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Is it possible to use different versions of a plugin in multi-project environment?

[Sneha]

Thanks Christian for the quick reply. The solution is really helpful.

Thanks,
Sneha
On Jun 8, 1:32 pm, Christian Boos cb...@neuf.fr wrote:
 Sneha wrote:
  Hi All,

  We are working on multi-project Trac environment. we have modified a
  plugin to suit a project's requirement. Is it possible to install this
  modified version of the plugin for a certain project and use the
  default (unmodified) version of the same plugin in all other?

 Not unless the modified plugin also uses a modified package name (i.e.
 if the source lived in tracpluginsomething/, rename that folder to
 tracpluginmysomething/ and update the setup.py file accordingly).
 Or refactor the change you did so that it only gets activated when some
 option is selected in trac.ini, and turn this on/off in the different
 environments.

 Hope this helps!

 -- Christian

  We are using easy-install --always-unzip  command to install plugins
  for all projects.

  Thanks,
  Sneha
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Is it possible to use different versions of a plugin in multi-project environment?

[Graham Dumpleton]

On Jun 8, 6:32 pm, Christian Boos cb...@neuf.fr wrote:
 Sneha wrote:
  Hi All,

  We are working on multi-project Trac environment. we have modified a
  plugin to suit a project's requirement. Is it possible to install this
  modified version of the plugin for a certain project and use the
  default (unmodified) version of the same plugin in all other?

 Not unless the modified plugin also uses a modified package name (i.e.
 if the source lived in tracpluginsomething/, rename that folder to
 tracpluginmysomething/ and update the setup.py file accordingly).
 Or refactor the change you did so that it only gets activated when some
 option is selected in trac.ini, and turn this on/off in the different
 environments.

Or use mod_wsgi daemon mode and delegate each project to a different
process group. This exact case is described in mod_wsgi documentation
for Trac integration. See:

  http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac

Graham

 Hope this helps!

 -- Christian

  We are using easy-install --always-unzip  command to install plugins
  for all projects.

  Thanks,
  Sneha
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: What documentiondto we want, were do we put it and how do we maintain it

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Cross-posted to trac-dev, as this thread should be moved there
 please reply only to trac-dev]

Olemis Lang skrev 04. juni 2009 22:29:
 On Thu, Jun 4, 2009 at 2:07 PM, Eirik Schwenke
 eirik.schwe...@nsd.uib.no wrote:

 I think we need to rethink (or document plainly on the wiki) the terms
 trac user and trac developer. trac end user and trac contributor
 might be better labels, a contributor being anyone that submits code
 (python, javascript, html and templates) or documentation (wiki,
 newhelp) changes.

 
 Let me see if I get the idea :
 
 - Contributor : a contributor being anyone that submits code
   (python, javascript, html and templates) or documentation (wiki,  newhelp)
   changes. (This one seems to be ok for me)
 - Trac developer : What's the difference between a Trac dev and a contributor
   that submits code ( checkin permissions ?)

Yes, my thinking was that trac-dev would be someone with commit access.
Apparently there should be no such thing as a trac dev, only trac
commiters  ...

 - trac user : ¿?
 - trac end user: ¿?  What's the difference

No difference, trac user and trac dev are the only old/legacy
terms that I've seen used before -- and my point was that those terms
weren't all that helpful for discussion.

As a side note, the term trac dev might be relevant as in: trac-dev:
someone that has a working knowledge of the internals of trac.

These are all small details - I believe my original comments had
something to do with defining the workflow, and the notion that not all
contributors (eg: doc writers) are / should be trac devs.

(...)

 I found: http://trac.edgewall.org/wiki/TranslationRu/TracAdmin, does
 this mean that case 4) would involve creating /TranslationJp/xx ?

 
 What about using Wiki Negotiation plugin ?

Is that plugin alive/working ? I had forgotten all about it -- I assume
you refer to: http://trac-hacks.org/wiki/TracWikiNegotiatorPlugin

The example site appears to be down -- but that doesn't mean the plugin
is dead.


There's still a question of managing all this stuff, which is somewhat
related to tagging/branching of documentation -- and possibly suggests
some changes to the wiki in future releases of trac.


An interesting project I worked with at the University of Trondheim had
some useful features for managing documentation:

 a) each article is contained in an xml-file (analogous to a wiki page)
 b) each has an author/owner
 c) the system sends out mail to each owner after x months, asking them
to verify that the article is still relevant, and either:
1) sign off (click ok)
2) update and sign off (ie: edit, sign off)
3) delete it

This is mostly workflow related, and could probably be implemented on
top of either rest/sphinx and/or the wiki.

The system is open, and has some multilingual content:

  http://infoweb.ntnu.no/about+infoweb/help/about.html
  (unfortunately it appears development is better maintainted
   than documentation, as can be seen from the warning on top of
   the following page):
  http://infoweb.ntnu.no/about+infoweb/info/technical.html

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkos+7sACgkQxUW7FIqjOSxJ+gCgoCXQ0gjIfkF04aVx1ciLP2SI
7WwAn3dH104+1Z2HEgkKM01heVodO2KU
=cIT9
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noah Kantrowitz skrev 04. juni 2009 22:13:
 Link to the last discussion on this (or at least one of the last)
 http://groups.google.com/group/trac-dev/browse_thread/thread/f79a1cbb894fe079/8e7d047d0c9fcf16
 
 --Noah

Thanks for the link -- didn't think to include it -- my questions re
syntax was partly motivated by the points made in that thread. I'd be
very interested to hear some more detailed views on ReST vs wiki markup
- -- right now I see two points in favour of the wiki markup:

  1) It's what a great number of trac users already know
  2) Existing trac macros already integrated with the trac
 wiki processor.

I'd be interested in hearing other points of view, especially against
ReST, as I might be blind to any real deficiencies others find crippling ?

Christian Boos mentioned the WikiEngine refactoring which will make it
possible to generate structured output (e.g. Genshi events or docutils
nodes, so that we could hijack the docutils writers for generating the
static documentation)

Has this taken place in trunk ?  I think the consensus is that there are
problems with managing documentation (exclusively) in the (any) wiki,
due to difficulties with maintaining separate versions (0.11, 0.12 as
well as multiple languages) -- but making it easier to do general
transforms on the wiki content would be great either way.

This is beginning to sound a bit like reinventing xml and xlst -- even
though I personally think working with either of those tend to be painful.


Christian further mentions: (Trac has) Much improved table markup (the
reST table markup is unbearable).

This would be:
http://trac.edgewall.org/wiki/WikiFormatting#Tables

vs:
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#grid-tables

I agree the trac simple syntax is easier than the rest simple syntax,
but I think unreadable is a bit strong ?

It does illustrate a major difference between ReST and TracWiki-markup:
Underline-markup vs side-by-side/inline-markup:

ReST:Trac:

Headline =Headline=


= = =||Cell1||Cell2||Cell3||
Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
Cell4 Cell5 Cell6
= = =


Mentioned in the thread on trac-dev is also the external dependencies
problem -- and I agree that that needs to be taken into accounts. I'm
not aware of any good way to ensure pdf-generation with included images
that does not touch a wide range of dependencies, however.

Also while a lot of the default ReST templates are horribly ugly -- the
ability to seamlessly generate LaTeX is a great benefit -- this is of
course something eg. docutils also would grant us.


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotBeEACgkQxUW7FIqjOSwwzgCbB9INW793O1X+5jzG+dD/cire
KI0AoIEOPqXQR5aDjtvp0zLZKorFAlRp
=y77G
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: New CookBook Page

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

abalter skrev 04. juni 2009 23:19:
 It is probably a bit premature, but I started this:
 http://trac.edgewall.org/wiki/CookBook/About
 
 I suggest we start making some recipes, and see how it goes.  Once we
 have a couple dozen, we might have a better idea for how to do the
 cookbook.
 
 In the mean time, should we use trac-wiki or ReST?

I think stuff in the wiki, as a rule should be wiki markup ?

While I might come off as a rambling rest champion in the other threads,
that is mostly related to permanent documentation, and offline editing
with a real editor.

I'm sure I can help with converting from Trac to ReST markup as a
penance for my heretic comments if a new consensus develops ;-)


- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotB0YACgkQxUW7FIqjOSzxTgCgnjOa32oFay8jUq7StXSO3QxQ
SE8AoMG2M0ifL8H10mdJiFycUvUI/cNY
=rPNa
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Jeff Hammel]

On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Noah Kantrowitz skrev 04. juni 2009 22:13:
  Link to the last discussion on this (or at least one of the last)
  http://groups.google.com/group/trac-dev/browse_thread/thread/f79a1cbb894fe079/8e7d047d0c9fcf16
  
  --Noah
 
 Thanks for the link -- didn't think to include it -- my questions re
 syntax was partly motivated by the points made in that thread. I'd be
 very interested to hear some more detailed views on ReST vs wiki markup
 - -- right now I see two points in favour of the wiki markup:
 
   1) It's what a great number of trac users already know
   2) Existing trac macros already integrated with the trac
  wiki processor.
 
 I'd be interested in hearing other points of view, especially against
 ReST, as I might be blind to any real deficiencies others find crippling ?

(this is all MHO, if that wasn't obvious).

Its easier to write Trac wiki than ReST.  I also find it more human readable.  
As a big fan of markdown languages, I was very enamored with ReST a few years 
ago.  Now, I think its mostly awful, not that there aren't things about Trac 
wiki that I would change.
 
 Christian Boos mentioned the WikiEngine refactoring which will make it
 possible to generate structured output (e.g. Genshi events or docutils
 nodes, so that we could hijack the docutils writers for generating the
 static documentation)
 
 Has this taken place in trunk ?  I think the consensus is that there are
 problems with managing documentation (exclusively) in the (any) wiki,
 due to difficulties with maintaining separate versions (0.11, 0.12 as
 well as multiple languages) -- but making it easier to do general
 transforms on the wiki content would be great either way.
 
 This is beginning to sound a bit like reinventing xml and xlst -- even
 though I personally think working with either of those tend to be painful.
 
 
 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).
 
 This would be:
 http://trac.edgewall.org/wiki/WikiFormatting#Tables
 
 vs:
 http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables
 http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#grid-tables
 
 I agree the trac simple syntax is easier than the rest simple syntax,
 but I think unreadable is a bit strong ?
 
 It does illustrate a major difference between ReST and TracWiki-markup:
 Underline-markup vs side-by-side/inline-markup:
 
 ReST:Trac:
 
 Headline =Headline=
 
 
 = = =||Cell1||Cell2||Cell3||
 Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
 Cell4 Cell5 Cell6
 = = =

I've come to the conclusion than doing any sort of complicated table with any 
markdown language is just horrible.  The whole reason to use a markdown 
language, vs WYSIWYG + HTML, is that it should be easy to read as text and easy 
to write.  I've seen tables in both Trac wiki and ReST that are just boggling.

 
 Mentioned in the thread on trac-dev is also the external dependencies
 problem -- and I agree that that needs to be taken into accounts. I'm
 not aware of any good way to ensure pdf-generation with included images
 that does not touch a wide range of dependencies, however.
 
 Also while a lot of the default ReST templates are horribly ugly -- the
 ability to seamlessly generate LaTeX is a great benefit -- this is of
 course something eg. docutils also would grant us.

I do agree that it would be nice to use something standard-ish, which is a plus 
for ReST.  That being said, I would miss Trac wiki syntax greatly.  The other 
alternative is to spin off Trac wiki (the markdown syntax, not the linking or 
macros or what not) into its own product.  I'd probably use it.  If other 
people would...I wouldn't want to guess.  ReST has a long history and people 
are reluctant to change.

Jeff

 Best regards,
 
 - --
  .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
 ( NSD ) Harald Hårfagresgate 29Rom 150
  '---'  N-5007 Bergentlf: (555) 889 13
 
   GPG-key at pgp.mit.edu  Id 0x8AA3392C
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iEYEARECAAYFAkotBeEACgkQxUW7FIqjOSwwzgCbB9INW793O1X+5jzG+dD/cire
 KI0AoIEOPqXQR5aDjtvp0zLZKorFAlRp
 =y77G
 -END PGP SIGNATURE-
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeff Hammel skrev 08. juni 2009 14:46:
 On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:
 Noah Kantrowitz skrev 04. juni 2009 22:13:
 
[ Note somehow icedove chokes on mutt's quoting, apologies if the
  indendation/quotemarkers are still wrong. Pretty sure this is a
  problem with icedove not mutt --- anyway:]

 I'd be interested in hearing other points of view, especially
 against ReST, as I might be blind to any real deficiencies others
 find crippling ?
 
 (this is all MHO, if that wasn't obvious).

Indeed, I might have made that explicit for my thoughts as well --- All
IMHO :-)

 
 Its easier to write Trac wiki than ReST.  I also find it more human
 readable.  As a big fan of markdown languages, I was very enamored
 with ReST a few years ago.  Now, I think its mostly awful, not that
 there aren't things about Trac wiki that I would change.
 

Interesting, maybe I'm at the point you were a few years ago. One great
advantage I failed to mention in favour of TracWikiMarkup, is ofcourse
wiki links -- it's perhaps one of the biggest failings of ReST.

On the other hand I've come to enjoy being able to have links/footnotes
in one place in the text, and link to them like: [LinkToNamedFootnote]_.

It does depend a bit on what one is writing.

I often find myself moving text around, and parts of ReST syntax is
better for that (section linking, footnotes/citations), and part of
trac-syntax is better (better support for auto numbered lists).

(...)

 I've come to the conclusion than doing any sort of complicated
 table with any markdown language is just horrible.  The whole
 reason to use a markdown language, vs WYSIWYG + HTML, is that it
 should be easy to read as text and easy to write.  I've seen tables
 in both Trac wiki and ReST that are just boggling.

Indeed. While I have little love for text editors, there's a definitive
need for rich content, that can accompany (hyper)text. I feel csv-tables
is a possible compromise -- but any table beyond the simplest ones needs
a rich editor IMHO.

(...)

 I do agree that it would be nice to use something standard-ish,
 which is a plus for ReST.  That being said, I would miss Trac wiki
 syntax greatly.  The other alternative is to spin off Trac wiki
 (the markdown syntax, not the linking or macros or what not) into
 its own product.  I'd probably use it.  If other people would...I
 wouldn't want to guess.  ReST has a long history and people are
 reluctant to change.

One of the benefits I see with ReST is that it seems to be solid design,
with great room to improve. It merges a lot of good ideas from
Markdown/Structured Text/LaTeX with reasonable readability.


I'd still like to see some example of ReST vs Trac that you feel
illustrates the readability issues. We'll probably still view them
differently though ;-)


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotDMUACgkQxUW7FIqjOSzS9gCgjn8V5KUGKLQDC0NM/6LCqH4y
dvEAnRG+4Rgdn+qJDaT6xl/uY98aHRws
=VEJK
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Jeff Hammel]

On Mon, Jun 08, 2009 at 03:06:13PM +0200, Eirik Schwenke wrote:
snip/
  Its easier to write Trac wiki than ReST.  I also find it more human
  readable.  As a big fan of markdown languages, I was very enamored
  with ReST a few years ago.  Now, I think its mostly awful, not that
  there aren't things about Trac wiki that I would change.
  
 
 Interesting, maybe I'm at the point you were a few years ago. One great
 advantage I failed to mention in favour of TracWikiMarkup, is ofcourse
 wiki links -- it's perhaps one of the biggest failings of ReST.

Just as a point of clarity, while wiki has come to mean (markdown formatting) + 
(linking syntax), I think of the two quite differently.  Linking + macros could 
(and IMHO should) be done as post-processing regardless of what the underlying 
markdown formatting is.
 
Jeff

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Olemis Lang]

On Mon, Jun 8, 2009 at 7:46 AM, Jeff Hammeljham...@openplans.org wrote:
 On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Noah Kantrowitz skrev 04. juni 2009 22:13:
  Link to the last discussion on this (or at least one of the last)
  http://groups.google.com/group/trac-dev/browse_thread/thread/f79a1cbb894fe079/8e7d047d0c9fcf16
 
  --Noah

 Thanks for the link -- didn't think to include it -- my questions re
 syntax was partly motivated by the points made in that thread. I'd be
 very interested to hear some more detailed views on ReST vs wiki markup
 - -- right now I see two points in favour of the wiki markup:

   1) It's what a great number of trac users already know
   2) Existing trac macros already integrated with the trac
      wiki processor.


(Besides) IMHO I also like Trac syntax because :

- It's extensible (macros + processors)
- It's more close to what humans have in mind when they
  write something (yes ! the users mental model do care :))
  e.g. TracLinks
- Productivity (one line generates one million :P)
- The only thing I like about ReST is the way it handles links.
  I mean, I write the link target just once and thereinafter I
  dont need to repeat the link URL anymore. OTOH using Trac
  wiki syntax I need to write [url text] everywhere I need to
  insert a link to some location. That's the only thing that
  makes me waste my time (and therefore I'm not comfortable
  with ...) but I can live with that . BTW this is also why links
  are frequently missing while using ReST, but also why its
  relatively simple to fix it IMHO .

but all this can also raise a number of incompatibilities | «dont know
what to do» situations for transformations (e.g. to obtain HTML, PDF,
...) | every body is doing it a different way. So that's hardly
against standards, but it is really powerful.

In fact I even use Trac wiki syntax to write my blog posts (Blogger).
In the end, (in this case) the only thing that matters is HTML ;)

 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).

[...]
 I agree the trac simple syntax is easier than the rest simple syntax,
 but I think unreadable is a bit strong ?

[...]

 I've come to the conclusion than doing any sort of complicated table with any 
 markdown language is just horrible.

Oh yes ! you 'r right.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Ethan Jucovy]

On Mon, Jun 8, 2009 at 8:46 AM, Jeff Hammel jham...@openplans.org wrote:

 I do agree that it would be nice to use something standard-ish, which is a
 plus for ReST.  That being said, I would miss Trac wiki syntax greatly.  The
 other alternative is to spin off Trac wiki (the markdown syntax, not the
 linking or macros or what not) into its own product.  I'd probably use it.
  If other people would...I wouldn't want to guess.  ReST has a long history
 and people are reluctant to change.


+1.  Trac wiki syntax is the first and only wiki-like syntax that I've been
able to remember how to use. :)  In fact I actually compose almost all my
documents, even outside of the Trac environment, in Trac wiki syntax at
least initially -- emails, notes to myself, first drafts of papers ... so
I'm sure I'd use such a product too.

egj

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] plugin gone missing

[Roger Oberholtzer]

Or at least I can't find it on trac hacks.

I seem to recall seeing a plugin that allowed you to add tags to a wiki
page so that only the part above the tag was edited when you clicked on
the tag. At the time I saw it, I was busy getting trac set up, and did
not want to add plugins until I saw what trac itself did. But now I want
to investigate this. Am I remembering wrong? Or just blind when looking
at trac hacks?

--
Roger Oberholtzer


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Christian Boos]

Eirik Schwenke wrote:
 Christian Boos mentioned the WikiEngine refactoring which will make it
 possible to generate structured output (e.g. Genshi events or docutils
 nodes, so that we could hijack the docutils writers for generating the
 static documentation)

 Has this taken place in trunk ? 

No, this is not yet started (0.13?).

  I think the consensus is that there are
 problems with managing documentation (exclusively) in the (any) wiki,
 due to difficulties with maintaining separate versions (0.11, 0.12 as
 well as multiple languages) -- but making it easier to do general
 transforms on the wiki content would be great either way.

 This is beginning to sound a bit like reinventing xml and xlst -- even
 though I personally think working with either of those tend to be painful.


 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).
   

The (Trac has) shortcut is quite misleading. I never said that the 
current Trac table markup is any better than the reStructuredText one...
What I actually said was:
...
I don't see why we should stop improving Trac abilities in this domain 
(producing documentation).
Here are some of the relevant *work items*:
- the WikiEngine refactoring which will make it possible to generate
structured output (e.g. Genshi events or docutils nodes, so that we
could hijack the docutils writers for generating the static documentation)
- Section editing (#1024) so that big pages like the FAQ could be
easily edited
- *Much improved table markup* (the reST table markup is unbearable)
- Lots of possible minor improvements to the syntax and rendering, in
order to make writing documentation a more enjoyable experience (i.e. we
have full control over the feature set)
...
(from http://groups.google.com/group/trac-dev/msg/4d2ae7546c67fba4?hl=en)

... so this was instead recognizing the weaknesses of both markups when 
it comes to tables.

 = = =||Cell1||Cell2||Cell3||
 Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
 Cell4 Cell5 Cell6
 = = =
   

The reStructuredText markup is easier to read, but a pain to write (the 
cells have to line up). The current Trac wiki is less trouble to write, 
but harder to read in the wiki source.

There are several improvements I'd like to do in the specific case of 
tables. One is to make it possible to use a wiki processor for big 
cells, e.g.
{{{
#!td
any multiline wiki markup here ...
(much like #!div)
}}}

Also, I just took the occasion of this mail to dump some some Wiki 
syntax enhancement ideas in 
http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting 
and there are some more ideas related to tables there.

-- Christian


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Olemis Lang]

On Mon, Jun 8, 2009 at 8:51 AM, Eirik Schwenkeeirik.schwe...@nsd.uib.no wrote:
 Olemis Lang skrev 08. juni 2009 15:24:
 On Mon, Jun 8, 2009 at 7:46 AM, Jeff Hammeljham...@openplans.org wrote:
 On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:
 (...)

 In fact I even use Trac wiki syntax to write my blog posts (Blogger).
 In the end, (in this case) the only thing that matters is HTML ;)

 Interesting. Those of you that use trac markup so extensively -- what
 part of the markup do you actually use?
 Are you mainly reffering to
 headers and linking, or also the various format (non structural, non
 semantic) stuff ?


Well I'll tell you about my blog (other people could tell you about
other things too ;) and mainly about a specific entry [1]_

- I use Dojo ...
- I use Trac CSS ...
- I use div macro for the collapsible panel stuff. The benefits are
  - Users only read a summary of the article
  - If they want to they read the full article
  - without navigating to a different page
  - I'm focused on writing my article and not on seting up the html + js
code needed for that.
  - *DONT LIKE BLOGGER EDITOR*. Even if there's a lot of effort in
there, it doesnt
help me much (too many clicks or otherwise pure HTML). Wiki is just
fast  great ...
- I use syntax highlighting (processors) for code snippets.
- I dont use ImageMacro because I dont know URLs to images beforehand, but I
  could ;)
- I use TracLinks for definitions and more
- I use iGoogleGadget macro (TracGViz plugin [2]_) for including
Gadgets in posts.
  (not in the article I mention :-/)
- I plan to implement more specific stuff to do many other things fast as hell.
- Header  linking of course ;)
- The `span + icon` thing for links (fast as hell as compared with plain HTML)

... but these days I've not much time :(

and all this is tremendously non-std, but is useful  that's what
matters for me .

 Just curios.


Dont if it helps and if it's related with the main subject; but u just
asked for it ;)

BE CAREFUL ! If you use all these ideas you'll be violating my
copyrights ... c'u in court   (

XD

.. [1] PyUMLGraph : Otra manera de contemplar el código

(http://simelo-es.blogspot.com/2009/06/pyumlgraph-mirando-al-codigo-de-python.html)

.. [2] TracGViz plugin
(https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Issue after upgrading...

[REM]

Hi.  I updated Trac to version 0.11.4 from 0.10.x.  In this process I
updated Python to 2.5 and PySQLite 2.4.0.  After the update I am
seeing an issue where when I create or update a ticket, after clicking
submit on the ticket page the next page displayed is Page cannot be
displayed.  Normally this would just show the ticket that you have
updated or created.  I can hit refresh and the page displays fine, but
for whatever reason, when I hit submit I get that error...

Any ideas why this is happening?

Thanks,
REM2500

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: ldap authentication and anonymous query

[Dimitri Maziuk]

On Sunday 07 June 2009 17:43:57 Sergio Charpinel Jr. wrote:
 Yes, but it works as one. Try and see your ldap log.
 It is in the LdapAuthStore module for AccountManager. But it was not
 working in my ldap 2.4 , just in 2.2. So I changed and did a real bind.

Easy fix (assuming your ldap server is firewalled off etc): change access to 
* from by * none to by * read in your slapd.conf (or do what you did and 
use a non-anonymous bind).

Yes, by * none worked in 2.2 with by anonymouth auth access to password 
and and by * read access to uid etc. They've changed something in 2.4 and 
forgot to tell us what it is.

Dima
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Ariel Balter]

Olemis,

I tried to look at your blog, but I think your formatter is broken or 
something.  Everything is coming out in some foreign language, I think 
Spanish or something.  Made it very hard to read and understand.  
Perhaps you should look into using a different markup scheme?

Xenophobically yours, Ariel

Olemis Lang wrote:
 On Mon, Jun 8, 2009 at 8:51 AM, Eirik Schwenkeeirik.schwe...@nsd.uib.no 
 wrote:
   
 Olemis Lang skrev 08. juni 2009 15:24:
 
 On Mon, Jun 8, 2009 at 7:46 AM, Jeff Hammeljham...@openplans.org wrote:
   
 On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:
 
 (...)
 
 In fact I even use Trac wiki syntax to write my blog posts (Blogger).
 In the end, (in this case) the only thing that matters is HTML ;)
   
 Interesting. Those of you that use trac markup so extensively -- what
 part of the markup do you actually use?
 Are you mainly reffering to
 headers and linking, or also the various format (non structural, non
 semantic) stuff ?

 

 Well I'll tell you about my blog (other people could tell you about
 other things too ;) and mainly about a specific entry [1]_

 - I use Dojo ...
 - I use Trac CSS ...
 - I use div macro for the collapsible panel stuff. The benefits are
   - Users only read a summary of the article
   - If they want to they read the full article
   - without navigating to a different page
   - I'm focused on writing my article and not on seting up the html + js
 code needed for that.
   - *DONT LIKE BLOGGER EDITOR*. Even if there's a lot of effort in
 there, it doesnt
 help me much (too many clicks or otherwise pure HTML). Wiki is just
 fast  great ...
 - I use syntax highlighting (processors) for code snippets.
 - I dont use ImageMacro because I dont know URLs to images beforehand, but I
   could ;)
 - I use TracLinks for definitions and more
 - I use iGoogleGadget macro (TracGViz plugin [2]_) for including
 Gadgets in posts.
   (not in the article I mention :-/)
 - I plan to implement more specific stuff to do many other things fast as 
 hell.
 - Header  linking of course ;)
 - The `span + icon` thing for links (fast as hell as compared with plain HTML)

 ... but these days I've not much time :(

 and all this is tremendously non-std, but is useful  that's what
 matters for me .

   
 Just curios.

 

 Dont if it helps and if it's related with the main subject; but u just
 asked for it ;)

 BE CAREFUL ! If you use all these ideas you'll be violating my
 copyrights ... c'u in court   (

 XD

 .. [1] PyUMLGraph : Otra manera de contemplar el código
 
 (http://simelo-es.blogspot.com/2009/06/pyumlgraph-mirando-al-codigo-de-python.html)

 .. [2] TracGViz plugin
 (https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz)

   

-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Ariel I Balter, Ph.D.
Postdoc
Biological Monitoring/Modeling
Fundamental and Computational Sciences Directorate

Pacific Northwest National Laboratory 
Mail:
PO Box 999, MS P7-58,Richland, WA 99352
Shipping:
790 6th Street, MS P7-58, Richland, WA 99354

Tel:  509-376-7605 
Cell:  509-713-0087
ariel.bal...@pnl.gov
www.arielbalter.com
www.pnl.gov 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

begin:vcard
fn:Ariel Balter, PhD
n:Balter;Ariel
email;internet:abal...@indiana.edu
tel;home:812-332-2721
tel;cell:812-219-4558
x-mozilla-html:TRUE
url:http://arielbalter.com
version:2.1
end:vcard

[Trac] Re: Trac wiki markup vs ReST

[Olemis Lang]

A little bit OT, oops !

On Mon, Jun 8, 2009 at 11:22 AM, Ariel Balterar...@arielbalter.com wrote:
 Olemis,

 I tried to look at your blog, but I think your formatter is broken or
 something.  Everything is coming out in some foreign language, I think
 Spanish or something.

Dont get it, it's in Spanish - I love spanish, french  english :) 
I've not learned yet ;) -. I thought that wouldnt be a problem to
depict the main idea (considering the question ;o).

I wanted to start a separate blog for each language but I've no time
for that, so I included Google Translate gadget in the top left corner
.

I'd really like to have more time, but I dont ... désolé:-/

 Made it very hard to read and understand.  Perhaps
 you should look into using a different markup scheme?


Dont get it ... what for ? Any suggestions will be welcomed : but I
personally think they should be sent to me directly unless they are
related to trac ;)

 Xenophobically yours, Ariel


Oh wow !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PyUMLGraph : Otra manera de contemplar el código  -
http://feedproxy.google.com/~r/simelo-es/~3/lLsxDz4Rkgc/pyumlgraph-mirando-al-codigo-de-python.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Python question

[Dan Winslow]

Can someone explain this construct to me?

 

errors = [(field_name, '%s is required' % field_name)

   for field_name in required_fields

   if self._is_empty(ticket[field_name])]

 

What does 'errors' contain? I can see that it's a list of some
sort...but the parenthetical grouping in the first line looks like it is
some kind of initializer for field_name...so what does it return? The
contents of field_name? and how does the for loop work...what's the
difference between the if returning false or true?

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Python question

[Ariel Balter]

errors contains a list of tuppes, each with two elements.  The first 
element in each tupple is a string, the field_name, and a second is 
the string that gets manufactured with %s is required' % field_name 
based on the value of field_name.

I'm guessing that the next thing is that the list errors will get 
zipped into a dictionary.  There is actually a way to make 
dictionaries with those kinds of expressions, but I don't remember the 
syntax off the top of my head.

Dan Winslow wrote:

 Can someone explain this construct to me?

  

 errors = [(field_name, '%s is required' % field_name)

for field_name in required_fields

if self._is_empty(ticket[field_name])]

  

 What does 'errors' contain? I can see that it's a list of some 
 sort...but the parenthetical grouping in the first line looks like it 
 is some kind of initializer for field_name...so what does it return? 
 The contents of field_name? and how does the for loop work...what's 
 the difference between the if returning false or true?

  

 Dan Winslow
 Director of Information Technology, AIM INSTITUTE
 1905 Harney Street, Suite 700
 Omaha, NE 68102
 402-345-5025 x156
 dwins...@aiminstitute.org mailto:dwins...@aiminstitute.org
 www.aiminstitute.org http://www.aiminstitute.org

  


 

-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Ariel I Balter, Ph.D.
Postdoc
Biological Monitoring/Modeling
Fundamental and Computational Sciences Directorate

Pacific Northwest National Laboratory 
Mail:
PO Box 999, MS P7-58,Richland, WA 99352
Shipping:
790 6th Street, MS P7-58, Richland, WA 99354

Tel:  509-376-7605 
Cell:  509-713-0087
ariel.bal...@pnl.gov
www.arielbalter.com
www.pnl.gov 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

begin:vcard
fn:Ariel Balter, PhD
n:Balter;Ariel
email;internet:abal...@indiana.edu
tel;home:812-332-2721
tel;cell:812-219-4558
x-mozilla-html:TRUE
url:http://arielbalter.com
version:2.1
end:vcard

[Trac] Re: Python question

[Emmanuel Blot]

 Can someone explain this construct to me?
You'd want to look for list comprehension documentation in Python

The code snipped can be rewritten as:

errors = []
for field_name in required_fields:
   if self._is_empty(ticket[field_name]):
  errors.append((field_name, '%s is required' % field_name))


     errors = [(field_name, '%s is required' % field_name)
        for field_name in required_fields
        if self._is_empty(ticket[field_name])]

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Python question

[Dan Winslow]

Thanks, very much, I was having trouble finding it in Python docs. I didn't 
know what to call it!

-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On 
Behalf Of Emmanuel Blot
Sent: Monday, June 08, 2009 12:04 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Python question


 Can someone explain this construct to me?
You'd want to look for list comprehension documentation in Python

The code snipped can be rewritten as:

errors = []
for field_name in required_fields:
   if self._is_empty(ticket[field_name]):
  errors.append((field_name, '%s is required' % field_name))


     errors = [(field_name, '%s is required' % field_name)
        for field_name in required_fields
        if self._is_empty(ticket[field_name])]



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Python question

[Dan Winslow]

Although...this 

errors=[]
errors.append(name,message)

gives

TypeError: append() takes exactly one argument (2 given

-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On 
Behalf Of Emmanuel Blot
Sent: Monday, June 08, 2009 12:04 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Python question


 Can someone explain this construct to me?
You'd want to look for list comprehension documentation in Python

The code snipped can be rewritten as:

errors = []
for field_name in required_fields:
   if self._is_empty(ticket[field_name]):
  errors.append((field_name, '%s is required' % field_name))


     errors = [(field_name, '%s is required' % field_name)
        for field_name in required_fields
        if self._is_empty(ticket[field_name])]



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Python question

[Ariel Balter]

Consider:
{{{#!python
field_names = [
   'first',
   'second',
   'third',
   ]

stuff = [(field_name, 'the field name is \%s\' % field_name) for 
field_name in field_names]

print(stuff)

print('\n\n')

more_stuff = dict(stuff)

for key, value in more_stuff.items():
   print(key + ':\t' + value)
}}}

Dan Winslow wrote:

 Can someone explain this construct to me?

  

 errors = [(field_name, '%s is required' % field_name)

for field_name in required_fields

if self._is_empty(ticket[field_name])]

  

 What does 'errors' contain? I can see that it's a list of some 
 sort...but the parenthetical grouping in the first line looks like it 
 is some kind of initializer for field_name...so what does it return? 
 The contents of field_name? and how does the for loop work...what's 
 the difference between the if returning false or true?

  

 Dan Winslow
 Director of Information Technology, AIM INSTITUTE
 1905 Harney Street, Suite 700
 Omaha, NE 68102
 402-345-5025 x156
 dwins...@aiminstitute.org mailto:dwins...@aiminstitute.org
 www.aiminstitute.org http://www.aiminstitute.org

  


 

-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Ariel I Balter, Ph.D.
Postdoc
Biological Monitoring/Modeling
Fundamental and Computational Sciences Directorate

Pacific Northwest National Laboratory 
Mail:
PO Box 999, MS P7-58,Richland, WA 99352
Shipping:
790 6th Street, MS P7-58, Richland, WA 99354

Tel:  509-376-7605 
Cell:  509-713-0087
ariel.bal...@pnl.gov
www.arielbalter.com
www.pnl.gov 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

begin:vcard
fn:Ariel Balter, PhD
n:Balter;Ariel
email;internet:abal...@indiana.edu
tel;home:812-332-2721
tel;cell:812-219-4558
x-mozilla-html:TRUE
url:http://arielbalter.com
version:2.1
end:vcard

[Trac] Re: Python question

[Dan Winslow]

Never mind, looks like I needed an internal paren, I guess to produce a 'tuple'

errors=[]
errors.append((name,message))

-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On 
Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 12:10 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Python question


Although...this 

errors=[]
errors.append(name,message)

gives

TypeError: append() takes exactly one argument (2 given

-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On 
Behalf Of Emmanuel Blot
Sent: Monday, June 08, 2009 12:04 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Python question


 Can someone explain this construct to me?
You'd want to look for list comprehension documentation in Python

The code snipped can be rewritten as:

errors = []
for field_name in required_fields:
   if self._is_empty(ticket[field_name]):
  errors.append((field_name, '%s is required' % field_name))


     errors = [(field_name, '%s is required' % field_name)
        for field_name in required_fields
        if self._is_empty(ticket[field_name])]





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Python question

[Emmanuel Blot]

 Never mind, looks like I needed an internal paren, I guess to produce a 
 'tuple'
Yeah ;-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] How to delete attachment | change desc @ TH.org ?

[Olemis Lang]

Well the subject is self explanatory ... I just commited a mistake and
uploaded the same file twice to TH.org wiki, so I'd like to delete one
of them and | or change their descriptions.

Thanks in advance !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: How to delete attachment | change desc @ TH.org ?

[Noah Kantrowitz]

What attachment? 

--Noah

 -Original Message-
 From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
 On Behalf Of Olemis Lang
 Sent: Monday, June 08, 2009 10:26 AM
 To: trac-users@googlegroups.com
 Subject: [Trac] How to delete attachment | change desc @ TH.org ?
 
 
 Well the subject is self explanatory ... I just commited a mistake and
 uploaded the same file twice to TH.org wiki, so I'd like to delete one
 of them and | or change their descriptions.
 
 Thanks in advance !
 
 --
 Regards,
 
 Olemis.
 
 Blog ES: http://simelo-es.blogspot.com/
 Blog EN: http://simelo-en.blogspot.com/
 
 Featured article:
 ¡ Bienvenido OpenSolaris 2009.06 !  -
 http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-
 opensolaris-200906.html
 
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: How to delete attachment | change desc @ TH.org ?

[Olemis Lang]

On Mon, Jun 8, 2009 at 12:26 PM, Noah Kantrowitzn...@coderanger.net wrote:

 What attachment?


Any of these

http://trac-hacks.org/attachment/wiki/PyTppThemePlugin/TracPyTppTheme-2.2.0.tar.gz

http://trac-hacks.org/attachment/wiki/PyTppThemePlugin/TracPyTppTheme-2.2.0.tar.2.gz

The fact is that I selected the wrong file (gztar) instead of egg. Sorry :-/.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PyUMLGraph : Otra manera de contemplar el código  -
http://feedproxy.google.com/~r/simelo-es/~3/lLsxDz4Rkgc/pyumlgraph-mirando-al-codigo-de-python.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: How to delete attachment | change desc @ TH.org ?

[Noah Kantrowitz]

Please don't upload eggs as attachments. They always end up out of date and
are just confusing. If you want to upload built eggs somewhere, use PyPI.

--Noah

 -Original Message-
 From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
 On Behalf Of Olemis Lang
 Sent: Monday, June 08, 2009 10:34 AM
 To: trac-users@googlegroups.com
 Subject: [Trac] Re: How to delete attachment | change desc @ TH.org ?
 
 
 On Mon, Jun 8, 2009 at 12:26 PM, Noah Kantrowitzn...@coderanger.net
 wrote:
 
  What attachment?
 
 
 Any of these
 
 http://trac-hacks.org/attachment/wiki/PyTppThemePlugin/TracPyTppTheme-
 2.2.0.tar.gz
 
 http://trac-hacks.org/attachment/wiki/PyTppThemePlugin/TracPyTppTheme-
 2.2.0.tar.2.gz
 
 The fact is that I selected the wrong file (gztar) instead of egg.
 Sorry :-/.
 
 --
 Regards,
 
 Olemis.
 
 Blog ES: http://simelo-es.blogspot.com/
 Blog EN: http://simelo-en.blogspot.com/
 
 Featured article:
 PyUMLGraph : Otra manera de contemplar el código  -
 http://feedproxy.google.com/~r/simelo-es/~3/lLsxDz4Rkgc/pyumlgraph-
 mirando-al-codigo-de-python.html
 
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Lance Hendrix]

Interesting thread and also interesting to see how much everyone likes 
Trac wiki syntax.  I will add my $0.02 US and also take as IMHO:

While I agree that simple text and things like TODO and instruction 
related documentation are relatively easy to do in markdown, I have 
(and it may be due to my lack of experience with) had difficulties with 
almost all mark down languages when it comes to technical 
documentation.  If it is simply a question of Trac wiki or ReST, then I 
don't really have a strong preference, but I would lean toward Trac wiki 
(as much as I like what I have reviewed and researched with regard to 
Rest) as then all my work with/around Trac would use a consistent 
format; however...

At the risk of (a strict interpretation of the thread) taking us off 
topic, I would also suggest that if we plan to leverage version 
controlled documentation for various releases that some of the 
limitations (tables being a big one) of markdown will become more 
significant and for that reason I would suggest at least considering 
another richer format.  As mentioned previously, I have settled on 
just such a format for the bulk of the content I develop and thankfully, 
the other OSS project I am working on also supports the same format for 
their documentation.  The advantages of these are their (obviously) 
richer format and (at least based on my limited knowledge of Trac wiki 
and ReST) ability to be easily transformed to other format and supported 
by a significant number of tools.  The is obviously more complex, but 
there are tools available to help assist with the development of the 
documentation (which is another big advantage of a standard mark up)...

Lance


Roger Oberholtzer wrote:
 On Mon, 2009-06-08 at 14:36 +0200, Eirik Schwenke wrote:

   
 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).

 This would be:
 http://trac.edgewall.org/wiki/WikiFormatting#Tables

 vs:
 http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables
 http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#grid-tables
 

 I do miss the ability to span columns and rows. Especially columns. If
 Trac had this, I would not need any change to the table syntax.

 I confess, I use the WYSIWYG trac plugin to manipulate tables. I get
 some pretty hefty ones, and adding a column can be a real PITA. Even if
 I cut/paste from my favorite vi. 

 --
 Roger Oberholtzer


 
   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Boos skrev 08. juni 2009 16:26:
 Eirik Schwenke wrote:
 Christian Boos mentioned the WikiEngine refactoring which will make it
 possible to generate structured output (e.g. Genshi events or docutils
 nodes, so that we could hijack the docutils writers for generating the
 static documentation)

 Has this taken place in trunk ? 
 
 No, this is not yet started (0.13?).
 

Ok, thanks for the update.


(...)
 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).
   
 
 The (Trac has) shortcut is quite misleading. I never said that the 
 current Trac table markup is any better than the reStructuredText one...
 What I actually said was:
 ...
 I don't see why we should stop improving Trac abilities in this domain 
 (producing documentation).
 Here are some of the relevant *work items*:
 - the WikiEngine refactoring which will make it possible to generate
 structured output (e.g. Genshi events or docutils nodes, so that we
 could hijack the docutils writers for generating the static documentation)
 - Section editing (#1024) so that big pages like the FAQ could be
 easily edited
 - *Much improved table markup* (the reST table markup is unbearable)
 - Lots of possible minor improvements to the syntax and rendering, in
 order to make writing documentation a more enjoyable experience (i.e. we
 have full control over the feature set)
 ...
 (from http://groups.google.com/group/trac-dev/msg/4d2ae7546c67fba4?hl=en)
 
 ... so this was instead recognizing the weaknesses of both markups when 
 it comes to tables.

Ah, my apologies. I must've read through that thread at too high
speed... Not sure how I managed to misread you so completely.

If it helps, I did find it very strange of you to make such an
out-of-character seemingly nonsensical comment ;-)


 
 = = =||Cell1||Cell2||Cell3||
 Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
 Cell4 Cell5 Cell6
 = = =
   
 
 The reStructuredText markup is easier to read, but a pain to write (the 
 cells have to line up). The current Trac wiki is less trouble to write, 
 but harder to read in the wiki source.

Agreed. As mentioned in this thread already, there are (currently) no
*good* alternatives -- personally I think the trac syntax has better
potential here -- but i'd like to see table headers.

 
 There are several improvements I'd like to do in the specific case of 
 tables. One is to make it possible to use a wiki processor for big 
 cells, e.g.
 {{{
 #!td
 any multiline wiki markup here ...
 (much like #!div)
 }}}

Hm... not sure if I agree
alternative-syntax-x-which-is-just-a-wrapper-for-html is better than just:

{{{
#!html
table
(...)
}}}

Both html and LaTeX have powerful (but IMNHO painful to read/write)
table markup.

I think that some kind of csv-table might be better -- in general I lean
quite strongly towards What-You-Mean vs What-You-Get syntax for markup.
This is somewhat related to the render-as-anything functionality which I
think is quite essential both for wiki and documentation.

(Eg: pdf/ps w/inline rich content such as vector/bitmap images, graphs,
tables, links; slideshows (ppt or s5), html, infotex etc).

 Also, I just took the occasion of this mail to dump some some Wiki 
 syntax enhancement ideas in 
 http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting 
 and there are some more ideas related to tables there.

Many interesting points.


I still think there is some disagreement (or non-explicitness) whether
wiki-markup shows meaning or appearance. Personally I prefer to mark up
meaning, even if that will always be abused for visual gain by
creative users.

Perhaps a strict, not-quite-so-friendly wiki markup coupled with a
simple-yet-powerful rich html/js-editor might be a good idea ?

That way, those that prefer to use eg It'sAllText-plugin with vim and
syntax-highlighting should be able to stay happy, as well as the more
casual users using only the web front-end ?

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotTfsACgkQxUW7FIqjOSxa3QCfYbOQ3vNHRysAMWtnesobrG3N
xdsAni6oh58zSUenHXff+iWywYcyGyIp
=RrhG
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: How to delete attachment | change desc @ TH.org ?

[Olemis Lang]

On Mon, Jun 8, 2009 at 12:37 PM, Noah Kantrowitzn...@coderanger.net wrote:

 Please don't upload eggs as attachments. They always end up out of date and
 are just confusing. If you want to upload built eggs somewhere, use PyPI.


Yes you 'r right . Thnx !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] custom fields

[Dan Winslow]

Are custom field values present in the the ticket[] list? If not is
there a custom_ticket[]? Else where can I get the value of a custom
field at ticket validation time.

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Ticket print?

[Dan Winslow]

I did this and my trac process went crazy, endlessly dumping lines to
log.

 

for t in ticket:

self.env.log.info(t)

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Ticket print?

[Olemis Lang]

On Mon, Jun 8, 2009 at 1:31 PM, Dan Winslowdwins...@aiminstitute.org wrote:
 I did this and my trac process went crazy, endlessly dumping lines to log.

     for t in ticket:
     self.env.log.info(t)


Wow ! What d'u wnat to do ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Ticket print?

[Dan Winslow]

Well...I thought it might print out the contents of Ticket.

-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On 
Behalf Of Olemis Lang
Sent: Monday, June 08, 2009 1:36 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?


On Mon, Jun 8, 2009 at 1:31 PM, Dan Winslowdwins...@aiminstitute.org wrote:
 I did this and my trac process went crazy, endlessly dumping lines to log.

     for t in ticket:
     self.env.log.info(t)


Wow ! What d'u wnat to do ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: ldap authentication and anonymous query

[Lance Hendrix]

I assume you are speaking of OpenLDAP (2.2 and 2.4)?

Lance

Dimitri Maziuk wrote:
 On Sunday 07 June 2009 17:43:57 Sergio Charpinel Jr. wrote:
   
 Yes, but it works as one. Try and see your ldap log.
 It is in the LdapAuthStore module for AccountManager. But it was not
 working in my ldap 2.4 , just in 2.2. So I changed and did a real bind.
 

 Easy fix (assuming your ldap server is firewalled off etc): change access to 
 * from by * none to by * read in your slapd.conf (or do what you did and 
 use a non-anonymous bind).

 Yes, by * none worked in 2.2 with by anonymouth auth access to password 
 and and by * read access to uid etc. They've changed something in 2.4 and 
 forgot to tell us what it is.

 Dima
   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: error validating fields

[Erik Bray]

On Fri, Jun 5, 2009 at 3:55 PM, Dan Winslowdwins...@aiminstitute.org wrote:
 I am attempting to modify some plugin code, despite my lack of python
 knowledge. I wanted to add type checking to the validator plugin, and so I
 added the modified  the function. With a trac.ini entry of



 [fieldscheck]

 int_fields=Hours



 and running this code :



     def validate_ticket(self, req, ticket):

     Make sure required fields for the next state have been

     the ticket will be in have been entered.



     state = self._get_state(req, ticket)



     editcheck_fields = self.config.getlist('fieldscheck','int_fields')



     errors = [(field_name, '%s must be an integer' % field_name)

   for field_name in editcheck_fields

   if self._is_not_integer(ticket[field_name])]



     required_fields = self.config.getlist('ticketvalidator',

   state + '.required')



     errors = errors + [(field_name, '%s is required' % field_name)

   for field_name in required_fields

   if self._is_empty(ticket[field_name])]



     return errors





 I get :

 TypeError: cannot concatenate 'str' and 'list' objects



 On the line :



 if self._is_not_integer(ticket[field_name])]



 I get the feeling this is just a python problem of mine and not something
 intrinsic to TRAC, but I thought I’d ask you guys anyways.



 Thanks in advance.

Probably need to see the rest of the code to be sure what the actual
problem is.  Also, your _is_not_integer() and _is_emtpy() methods seem
unnecessary.  The former can be replaced with `not
ticket[field_name].isdigit()` and the latter with `not
ticket[field_name]`, at least as far as I can tell from how they're
being used.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Wiki: Group Topics

[RJOllos]

Is it possible to remove the prefix.  For example,

[[TitleIndex(PageTemplates/)]]

results in:
* PageTemplates/ProcedureType1
* PageTemplates/ProcedureType2

However, it would be nice if the result was:
* ProcedureType1
* ProcedureType2

Similarly, on the Title Index page I have several pages that are
displayed as:
* AcousticTestAndMeasurement
* AcousticTestAndMeasurement/ImpedanceMeasurement
* AcousticTestAndMeasurement/PulseEchoMeasurement

However, it would be nice if they where displayed in a hierarchy as:
* AcousticTestAndMeasurement
* ImpedanceMeasurement
* PulseEchoMeasurement

Thanks,
- Ryan

On May 31, 4:55 pm, Olaf Meeuwissen olaf.meeuwis...@avasys.jp wrote:
 Roger Oberholtzer roger.oberholt...@gmail.com writes:
  On May 30, 2009, at 1:10 PM, ptrash wrote:

  Hi,

  is it possible to group topics, e.g. in the link TitleIndex I see:

  Trac
     * TracAccessibility
     * TracAdmin
     * TracBackup
     * TracBrowser
     * ...

  or
  Wiki
     * WikiDeletePage
     * WikiFormatting
     * WikiHtml
     * WikiMacros

  So there is a list of all trac (or wiki) topics.

  I think this happens automatically, based on the name of the page.

 The TitleIndex macro takes a few arguments that can be used to tweak
 the behaviour.  Have a look at the WikiMacros documentation.

  My only request would be that TestProcedureTprofilePP be grouped with  
  the other TestProcedure items instead of the strict alphabetical  
  method used.

 That doesn't seem to be supported.

 Hope this helps,
 --
 Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
 FSF Associate Member #1962               Help support software freedom
                  http://www.fsf.org/jf?referrer=1962
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] CalendarpopupPlugin

[Dan Winslow]

Anyone have any idea how CalendarPopupPlugin is supposed to work? How do
you get date popup fields configured?

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: CalendarpopupPlugin

[Dan Winslow]

Never mind, figured it out.

 



From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 2:46 PM
To: trac-users@googlegroups.com
Subject: [Trac] CalendarpopupPlugin

 

Anyone have any idea how CalendarPopupPlugin is supposed to work? How do
you get date popup fields configured?

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: custom fields

[Dan Winslow]

 

Answer : Yes, they are in the ticket[] list. I was having trouble with
something uppercasing the first character of the field name, causing the
lookup to fail.



From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 1:22 PM
To: trac-users@googlegroups.com
Subject: [Trac] custom fields

 

Are custom field values present in the the ticket[] list? If not is
there a custom_ticket[]? Else where can I get the value of a custom
field at ticket validation time.

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Ticket print?

[Dan Winslow]

It was in a validate_ticket callback in the ticketvalidator plugin. 

 

def validate_ticket(self, req, ticket):

Make sure required fields for the next state have been

the ticket will be in have been entered.

 

state = self._get_state(req, ticket)

  

 for t in ticket:

 self.env.log.info(t)

 



From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Noah Kantrowitz
Sent: Monday, June 08, 2009 2:47 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

You would have to be far more specific. Where is this?

 

--Noah

 

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 11:32 AM
To: trac-users@googlegroups.com
Subject: [Trac] Ticket print?

 

I did this and my trac process went crazy, endlessly dumping lines to
log.

 

for t in ticket:

self.env.log.info(t)

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 

 

 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Ticket print?

[Noah Kantrowitz]

ticket should be a ticket object, not sure that even supports iteration or
what it would mean to do so.

 

--Noah

 

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On
Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 12:51 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

It was in a validate_ticket callback in the ticketvalidator plugin. 

 

def validate_ticket(self, req, ticket):

Make sure required fields for the next state have been

the ticket will be in have been entered.

 

state = self._get_state(req, ticket)

  

 for t in ticket:

 self.env.log.info(t)

 

  _  

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On
Behalf Of Noah Kantrowitz
Sent: Monday, June 08, 2009 2:47 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

You would have to be far more specific. Where is this?

 

--Noah

 

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On
Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 11:32 AM
To: trac-users@googlegroups.com
Subject: [Trac] Ticket print?

 

I did this and my trac process went crazy, endlessly dumping lines to log.

 

for t in ticket:

self.env.log.info(t)

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 

 

 

 



 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Ticket print?

[Dan Winslow]

Apparantly it means LOTS of iteration...

 

If I had to guess I'd say that it wound up trying to iterate over the
entire index range of the item...say from 0 to maxint or something like
that.

 



From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Noah Kantrowitz
Sent: Monday, June 08, 2009 3:01 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

ticket should be a ticket object, not sure that even supports iteration
or what it would mean to do so.

 

--Noah

 

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 12:51 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

It was in a validate_ticket callback in the ticketvalidator plugin. 

 

def validate_ticket(self, req, ticket):

Make sure required fields for the next state have been

the ticket will be in have been entered.

 

state = self._get_state(req, ticket)

  

 for t in ticket:

 self.env.log.info(t)

 



From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Noah Kantrowitz
Sent: Monday, June 08, 2009 2:47 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Ticket print?

 

You would have to be far more specific. Where is this?

 

--Noah

 

From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Dan Winslow
Sent: Monday, June 08, 2009 11:32 AM
To: trac-users@googlegroups.com
Subject: [Trac] Ticket print?

 

I did this and my trac process went crazy, endlessly dumping lines to
log.

 

for t in ticket:

self.env.log.info(t)

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 

 

 

 

 

 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: ldap authentication and anonymous query

[Dimitri Maziuk]

On Monday 08 June 2009 13:50:13 Lance Hendrix wrote:
 I assume you are speaking of OpenLDAP (2.2 and 2.4)?

Yep.

Dima
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[yoheeb]

FYI, you link to your copyright on your web site points to a non-
existent file in your source control browser.

I'd like to read it.  I was very interesting in your GraphViz plugin,
but based on your comments i am not scared off a bit, depending on
what you copyright actually says.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Count Incoming tickets by milestone, and count closed tickets by milestone and user.

[yoheeb]

On Jun 4, 4:21 pm, Lukasz Szybalski szybal...@gmail.com wrote:
 On Jun 3, 4:55 pm, Lukasz Szybalski szybal...@gmail.com wrote:



  On Jun 3, 3:34 pm, yoheeb yoh...@gmail.com wrote:

   On Jun 3, 2:10 pm, Lukasz Szybalski szybal...@gmail.com wrote:

On Jun 2, 3:54 pm, Lukasz Szybalski szybal...@gmail.com wrote:

 Hello,
 I'm trying to get management reports for the following:

 1. Count Incoming tickets by milestone sort by date,  (30 new tickets
 for milestone on 06-02-09)
 2. Count closed tickets by milestone and user.  (25 tickets closed by
 xyz on 6-2-09)(list a count by user in each milestone)
 3. lookup by custom field? (custom field = account_number) (With query
 I can do that, but how do I put it on a wiki so that they can type in
 account# and press query or something along these lines.)

 Where can I find examples on how to do this?
snip
 how can I convert t.time to a date, so that I can group by t,time as a
 date and not as a datetime??

 Right now this query groups by datetime object and I need it to order
 by date only.

 SELECT time as created,time,milestone, count(*) AS 'Count of Tickets'
   FROM ticket
   WHERE status IN ('closed') AND time  strftime('%s',datetime
 (now,-14 days))+0
 GROUP BY (milestone IS NULL), milestone, created

 How to convert time into date like 20090604???

 Thanks,
 Lucas



  and the second query
  select user, milestone, count(*) , from ??  where status = fixed group
  by user, milestone, closeddate

An example of some queries that select things by date/time can be
found in this thread:
http://groups.google.com/group/trac-users/browse_thread/thread/83c426562091c253/d1da6fdc7e5eac84?hl=enlnk=gstq=between+dates#d1da6fdc7e5eac84

what you are after is the 'unixepoch', 'localtime') as closedate
partI think
assuming sqllite.  If you are on postGres, I can't help you, my SQL is
weak!, and I have never used postGres, so I don't know the variance.

The key in that thread that might be useful in your case, they
actually test for a transition to a specific state.  In your case, you
probably only need the creation date if date today, or today -14.
The html form for submission, on the other hand, would be cool to
know.  I am still of the mind that the best web browser to use in
lynx, and that if I bury my head long enough, the whole idea of web
forms etc will just pass me by :D

Now to go figure out this new fandangled mouse thingy

:wq
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Is it possible to use different versions of a plugin in multi-project environment?

[yoheeb]

Wow, so cool.  I am repeatedly amazed at how thorough the Trac dev/
features/implementation has been up to now.  There is practically no
use case that hasn't been thought of and a supporting implementation
put in place in core for it, much of which has already been
implemented by way of plugin, macro, patch, or other

This is one thing I wouldn't of even thought of, but I see how useful
it would be.

Kudo's
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Olemis Lang]

On Mon, Jun 8, 2009 at 3:37 PM, yoheebyoh...@gmail.com wrote:

 FYI, you link to your copyright on your web site points to a non-
 existent file in your source control browser.

 I'd like to read it.  I was very interesting in your GraphViz plugin,
 but based on your comments i am not scared off a bit, depending on
 what you copyright actually says.

If you 'r talking about TracGViz plugin then it is distributed under
the Apache License and distributes gviz_api module under the same
terms (and under permission from Google ;). All this is documented in
COPYRIGHT and NOTICE files included in both source and EGG packages .

TracPyTpp is distributed under the same terms of the original
implementation PyDotOrg theme which is BSD licence ... AFAICR ...
(Yes, I dont like interactions between Licences, specially when I've
just done 5% of the whole ;)

So dont worry ... was a little JOKE ! (I even wrote a smiley like this
XD, didnt I? )

If not talking about TracGViz, sorry I thought I should reply, but it
was not clear in your previos message -and TracGViz is not related to
GraphViz- ;)

Dont worry : All that is plain FOSS ... just use it  :)

PS: If you want a comprehensive understanding of all terms and so on,
please also read the Terms of Service for Google Visualization API and
iGoogle Gadgets. They are SaaS products provided by Google.

Good luck !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
¡ Bienvenido OpenSolaris 2009.06 !  -
http://feedproxy.google.com/~r/simelo-es/~3/UY8IF3M3Alw/bienvenido-opensolaris-200906.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Hiding fields

[Dan Winslow]

Is it possible to hide fields based on the current state? Ie., to have a
field not show up on the create form but be displayed in later states?

 

Dan Winslow
Director of Information Technology, AIM INSTITUTE
1905 Harney Street, Suite 700
Omaha, NE 68102
402-345-5025 x156
dwins...@aiminstitute.org
www.aiminstitute.org

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Wiki: Group Topics

[Christian Boos]

RJOllos wrote:
 Is it possible to remove the prefix.  For example,

 [[TitleIndex(PageTemplates/)]]

 results in:
 * PageTemplates/ProcedureType1
 * PageTemplates/ProcedureType2

 However, it would be nice if the result was:
 * ProcedureType1
 * ProcedureType2

 Similarly, on the Title Index page I have several pages that are
 displayed as:
 * AcousticTestAndMeasurement
 * AcousticTestAndMeasurement/ImpedanceMeasurement
 * AcousticTestAndMeasurement/PulseEchoMeasurement

 However, it would be nice if they where displayed in a hierarchy as:
 * AcousticTestAndMeasurement
 * ImpedanceMeasurement
 * PulseEchoMeasurement
   

Coming soon (http://trac.edgewall.org/ticket/6063).

-- Christian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Christian Boos]

Eirik Schwenke wrote:
 Christian Boos skrev 08. juni 2009 16:26:
   
 There are several improvements I'd like to do in the specific case of 
 tables. One is to make it possible to use a wiki processor for big 
 cells, e.g.
 {{{
 #!td
 any multiline wiki markup here ...
 (much like #!div)
 }}}
 

 Hm... not sure if I agree
 alternative-syntax-x-which-is-just-a-wrapper-for-html is better than just:

 {{{
 #!html
 table
 (...)
 }}}
   

It's not at all comparable. Within an !html block, you can't use any 
Wiki markup.
And since 0.11, you can't use the older trick of starting a 
table/row/cell in one !html block, close it and interleave some wiki 
markup, open a another  !html block for closing the cell/row/table, etc. 
Starting with 0.11, the HTML markup in an !html block has to be 
self-contained (see http://trac.edgewall.org/wiki/WikiHtml for details).

-- Christian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Report showing closed tickets for active milestones, ordered by workflow ...

[futnuh]

If a milestone only contains closed tickets, we assume it is completed
and don't need to see it.  However, if a milestone contains active
tickets, we'd like to see *al*l tickets pertaining to this milestone -
including closed (resolved) ones.  As a starting point, I'd like to
use the following report, slightly customized to our site

pre
SELECT p.value AS __color__,
   'Milestone '||milestone AS __group__,
   id AS ticket, summary, component, t.type AS type,
   owner, status, c.value AS estimate,
   time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name =
'estimate')
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE status  'closed'
  ORDER BY milestone DESC, (milestone IS NULL), t.status, CAST(p.value
AS int), t.type, time
pre

To top it off, we'd like to order the tickets not by status but by
workflow.  Our workflow proceeds through status = new, team_reviewed,
agreed, assigned, needs_review, reviewed, merged.  At this point the
ticket gets closed.  (Note that closed isn't a status ... but for the
purposes of ordering 'closed' tickets should appear last under the
relevant milestone.)

Any help with this would be much appreciated.

Cheers,
Darran.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---