IMHO, this isn't a matter of either-or, but of concurrent development along
2 related tracks:
You're right, it doesn't have to be either-or.
[snip]
It would be good to have (1) ASAP.
There's no reason that people who are interested in (2) have to be
interested in (1) or vice versa.
I agree
I'll be honest, I was willing to put in some effort for something
substantial and original, but I'm not too keen on just remaking or
porting an old solution.
M.T.
A simple, if naive fix could be to make the logo a phonetic
representation (or whatever it's called). Just a simple
pseudo-solution.
M.T.
I really like these. I think you're on to something. I'm definitely in
favor of Momi Wiki, or just Momi.
Maybe we can even be very corny and call it 'Aloha Wiki'... Hmm.
Yes, Bikini Wiki sounds sexy. I like how they both 'lie' in the
pacific ocean... as opposed to being worn... ;)
M.T.
I'll be honest and say that I'm not too concerned with the
prize/grant, so that may be the reason I want to go beyond that
minimal ideal. I'm specifically concerned with a poorly designed (or
at least slightly clumsy to upgrade) wiki, all in for the sake of
speed, minimal functionality, and money.
1) Understood. I've been disconnected from Perl for a while, and this
is really the first time I've been participating in the Perl
community. Thanks for the heads-up. :)
2) I agree that it is both important and pertinent to get the general
requirements down for the project, but I do see a need an
[Sorry Michael, I didn't mean to send it you twice. :) ]
I like the RFC idea. I will read up on them and see, if it is a
particular format, how to simplify it. But, most definitely, the
community must have dialog about the requests. For each request
really.
On the architecture note, I've written
Honestly, I'm not familiar with the Perl way of doing things, but I'm
open to learn especially because I see the Perl community going
through a (much-needed) reform. Thusly, I'm not familiar with the RFCs
(Request For Change?) but I do see the merit for something similar.
However, as far as the j
I was just reading the AES referenced above and I can say now that I'm
really happy about some changes to Regexes, and that a grammar may
well be what we're looking for. However, even with this great tool, we
still have to handle the implementation. Though I can see the benefit
of using the gramma
I would recommend using a templating system as opposed to having calls
to include files in numerous pages. Even though it's minimal, it's
still duplication, and it can get rather messy.
I know that some people don't know about or don't like it, but I would
recommend setting things up in a Model-V
Juerd,
My mistake: I misunderstood what you were saying (probably due to haste).
But really, then, there are alternatives to using tables, such as
DIVs, as well as simply modifying the parsing step to also parse for
this special case in addition to Textile or what-have-you.
I guess if I said an
I also agree that Object Oriented Design would work wonderfully well
here. The key here is prototyping its shape and then filling in the
details once it has taken this shape.
I like the term 'messages' for methods because it reminds me that the
objects must send requests, forms of communication,
There are alternatives to using tables for side-by-side using
paragraphs. Simply having one cell for each line, for instance, allows
for highlighting green the added lines and red the removed ones, etc.
Also realize that it is not necessarily the duty of Textile (et al) to
handle that aspect beyo
Iraq invasion indeed wait, shouldn't go there.
I particularly like the syntax of Textile or even Markdown (preferring
the former). In Ruby-land, these exist as RedCloth and BlueCloth. I
understand porting isn't fun, but I think that this is a viable
option, if not a great choice.
Not that th
14 matches
Mail list logo
