> * What would be nice if you could work with tabs! Like \t gets
> converted to a real tab, or something. I often use tabs for simple
> aligning and stuff.
Does html support tabs?
> * Is it really necessary to use all the different tags for functions/
> commands? I would be a lot easier if you just always could use [[..]]
> for links and {..} for variables and [{..}] for functions or
> something. I haven't looked at the code, and I do not know how PHP's
> regex functions work, but i though of some recursive function. I mean:
Regex is not recursive. You would have to write special code keeping
track of opening and closing brackets, and only use regexps for the
opening brackets, which is something of a headache. However, we could
migrate to a parser generater, like gnu bison. This could solve all
our problems. And possibly cure cancer, although thats just a rumour.
>
> while (match for [(..)])
> str[] = the match for [(..)]
> for (i = end to begin)
> str(i) = process_function
Either you have greedy or non greedy regexps. Greedy would take the
first [( and last )], giving error on: [( ... )] ... [( ... )] while
non greedy would give error on: [( [( ... )] )].
Moving away from regexps is the way to recursion.
> Further, it would be nice if PHP in code.embed page gets executed, and
> if you can save/edit the config.php, plugins, etc.
php plugins written directly in boltwire? I like.
> I have also found another bug:
> [(include group.boys lines=1)]
> [(include group.boys lines=3)]
>
> only retrieves the first line, the third line is not retrieved!
The code that avoids recursion loops. Have you considered simply
putting a max-recursion depth? only allow 100 includes per request?
> I also would like to be able to override the login and register
> functions, which is currently not possible. Also, you can login with
> your e-mail, but if multiple persons register with the same e-
> mail,..only the first person can login! So, there should be a check if
> the e-mail adress already exists. But not by default, because probably
> not everyone wants that.
This doesn't exist? hell yes by default! People expect one login per
person and it makes our lives easier. There is no bad...
> Also, if the e-mail adress is the unique name
> you need to login, you can easily have the same member names. In
> short: there should be an option whether to use member-name or e-mail
> for registering. The one you use for registering, that what should be
> allowed only once. For e-mail adresses you have the problem that @'s
> and dots get converted, so perhaps the ID (or login page) should be
> converted to something like: markmarijnissen[at]gmail[dot]com or
> whatever.
I dunnu. If you want this, just save email directly as {member} and
use some other variable to retrieve a name.
> That are my thoughts on the subject. Excellent work, this boltwire.
And the thoughts are quite excellent to. Good show, the both of you.
>
> cheers, Mark
> On Aug 2, 5:51 am, The Editor <[email protected]> wrote:
>
> > I'm exploring other possibilities as well for change. I'm particularly
> > looking for functions/commands that work in weird or arcane ways. Or
> > don't really get much use. The more we can trim BoltWire down to the
> > most common simple straightforward functions, the better. For
> > example:
>
> > The data function allows you to set certain prescribed data fields on
> > a page using a function. Clever. But once that code is put on the
> > page, it tells BoltWire to resave the data variable every time it
> > loads the page. Highly inefficient. I think there might be some
> > isolated uses for it, but at the very least it could be shunted off to
> > a plugin or something don't you think?
>
> > What about the getline function, which allows you to retrieve line 7
> > of some.page? Do we really need that? I thought it was a system
> > function, but it doesn't seem to be used anywhere else in the code.
> > Possibly an action page though I can't imagine which one. Shouldn't
> > this be a plugin as well?
>
> > There's also a thread function. I'm not sure it is really necessary in
> > the core. We already have the page.# shortcut, and therefore as a
> > result, never really use the function form. It might be useful, but
> > hardly essential. I think perhaps we should move this function to a
> > plugin.
>
> > Overwrite and zones are also rarely used, but they do come in handy
> > for specific actions: plugins and zones respectively. So I guess we
> > will have to keep them in there. Similarly, nocache and touch, are
> > used in the caching system. And therefore probably should stay in the
> > core. Other than these four and the three mentioned above, I think the
> > rest are all well used and highly functional.
>
> > The commands look a little better. Nothing there too much to worry
> > about. We have the touch command of course, and would possibly need to
> > add a math command if we split the counter function into math and
> > counter.
>
> > I see no major changes in the conditions worth making (adding or
> > subtracting),
>
> > Looking over the markups page I see some possibilities for improvement:
> > * Snippets perhaps should be in the pre group rather than vars, much
> > like embed is
> > * The various vars patterns could be rewritten so that the member vars
> > shortcut could be processed by BOLTvars, easily enough.
> > * Is anyone using wikiwords? I'd personally just as soon eliminate
> > support for it. Simplifies the code and goes against our strategy of
> > making everyrthing case insensitive. We could also put the pattern in
> > a plugin if we desired--just we would lose case insensitivity.
> > * Can't the headers pattern be rewritten so they don't need the
> > leading line return. Something like (not tested)
> > /(.*\<\;)?(!{1,6})(.*)/me'
> > * Can't we reduce the indent rules into one rule? Esp now that we are
> > requiring them to be at the beginning of a line. Should be easy
> > enough.
> > * Do we want to include hyperlinks in the bolt styles function. After
> > all, we already have styles allowed in regular [[links]]
>
> > There are also some awkward looking patterns, regarding bullets,
> > styles, spacing and lines, etc., but they are the best I can come with
> > at the moment. And no desire to go back in and try to rework them.
>
> > Well so much for thinking out loud. Feedback welcome...
>
> > Cheers
> > Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
