Hi Dan,

* 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.
* 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:

while (match for [(..)])
str[] = the match for  [(..)]
for (i = end to begin)
str(i) = process_function

same could be done for the nested if's.

Further, it would be nice if PHP in code.embed page gets executed, and
if you can save/edit the config.php, plugins, etc. Than you can really
edit and configure boltwire from the browser. Although i propably
still keep using notepad2 for the syntax highlighting.

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!

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. 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.

That are my thoughts on the subject. Excellent work, this boltwire.

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)
>      /(.*\&lt\;)?(!{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
-~----------~----~----~----~------~----~------~--~---

Reply via email to