+++ /dev/null
-Those are beautiful templates -- can you share those? I'd love to
-study the HTML and CSS behind them.
-
-On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote:
-> Hey Chris, thanks for the comments.
->
->>
->> My initial impression is that this looks good enough already to merge as
->> a replacement for the turbogears site. What does everyone else think?
->>
->
-> I'm not quite sure it's there yet. There are a bunch of bugs I've got
-> marked as "beta" that I'd like to see fixed before it's ready for real use.
-> Hopefully they shouldn't be too tough to fix. You can point CFBE at itself
-> to see them. :)
->
->> Could you explain a little about how you handle authorship of bug
->> changes at the moment, and if it looks plausible to try making it
->> multiuser? (Having it handle more than one "user" logged in at once.)
->>
->
-> That's something I need advice on. Right now CFBE is pretty much only
-> suitable for local use - you check out whatever you're working on and use it
-> as a local interface to the bugs in the repository. Change those, check in,
-> etc. It's effectively just a pretty version of the command line be tool.
->
-> I haven't used CherryPy's session/authentication support before. This might
-> be a good time for me to learn. One way it might be able to handle multiple
-> users hitting a central server:
->
-> * Each user has to register with the server and be approved by an admin.
-> * Each account would be mapped to a contributor string, the same one that
-> would show up if you were going to commit to the repository.
-> * Once you have an account, you'd login to make any changes.
->
->
-> Aside from all that, I'm a little fuzzy on how a centralized interface to a
-> distributed bug tracking system should work. A read-only interface to a
-> central "main" repository would be easy. Run the server in read-only mode
-> pointing at the main repository. People can use it to look at the bugs in
-> the tip of that repository.
->
-> If it's not read-only, what happens when a user changes/adds/whatevers a
-> bug? Should CFBE commit that change to the repository right then and there?
-> Should it never commit, just update the bugdir and let the commits happen
-> manually?
->
-> What happens when you have multiple branches for a repository? Should there
-> be one CFBE instance for each branch, or a single one that lets you switch
-> between branches (effectively switching between revisions)?
->
-> Those are the kind of things that don't really apply when CFBE is just a
-> local interface to a single repository. If anyone has any advice on how a
-> multi-user interface should work I'd love to hear it!
->
-> --
-> Steve Losh
-> http://stevelosh.com/
->
->
-> _______________________________________________
-> Be-devel mailing list
-> Be-devel@bugseverywhere.org
-> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
->
-
-
-
---
-Matthew Wilson
-matt@tplus1.com
-http://tplus1.com
-
-_______________________________________________
-Be-devel mailing list
-Be-devel@bugseverywhere.org
-http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
Speaking of that interface, I changed up the look and feel a bit last
weekend. It's still at http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
-- if anyone has any feedback (on any aspect of it) I'd appreciate it.
-
---
-Steve
-
-On Jul 3, 2009, at 8:31 PM, Chris Ball wrote:
-
-> Hi Gianluca,
->
->> As i said in a previous mail, I am working on a "html" command
->> for be. The goal is to be able to do something like "be html
->> /web/page" to have in the /web/page directory some static html
->> pages that basically are the dump of the be repository, much like
->> ditz have. This will enable a simple and fast publish of the bus
->> list and details on the web, at least in read only mode.
->
-> It might be a good idea for "be html" to use the CherryPy web
-> interface
-> that Steve is working on. The command could start up the CherryPy app
-> and scrape all of the available pages to get a stand-alone dump; this
-> would avoid having to keep two (okay, more than two at this point)
-> separate sets of HTML templates in the source tree. What do you
-> think?
->
->> 2) I see that every command is implemented with a python file in
->> the becommand dir. For a better code, I'd like to split the
->> command implementation into two files: a file that contain the
->> actual code and a second file that have the html related part,
->> any problem with this ? I don't like to have the html part and
->> the code part in one big and unreadable file.
->
-> I agree that becommands/*.py commands should not contain any HTML
-> layout code. Putting it somewhere else instead sounds fine.
->
-> Thanks!
->
-> - Chris.
-> --
-> Chris Ball <cjb@laptop.org>
->
-> _______________________________________________
-> Be-devel mailing list
-> Be-devel@bugseverywhere.org
-> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
-
-
-_______________________________________________
-Be-devel mailing list
-Be-devel@bugseverywhere.org
-http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
projects / be.git / commitdiff