How do you expect us to come up with more than general handwaving suggestions if you don't show any code and only tell us about your framework as a black box?
Well the thing is, having learnt what I have learnt about things like catalyst etc, even I can slag my own code off as being extremely naive, i'm not so much trying to get people to fix my code, as to present the syntax I wrote it to work with, in the hope that if someone can grasp the nature of the syntax itself (and why it rocks) they will realise why I either need help with it or I'm going to spend the next 3-5 years of my life hacking away at it alone in the dark.
here is a rough pseudo-code of what the parser does... please don't laugh too much!
load plugins, build plugin hash table
load appropriate body.aXML
while ( commands_remain_unprocessed )
{
for each plugin_name in plugins hash
{
scan using a regex for a corresponding tag
making sure it does not contain any subtags
if tag has been found that is ready to be
computed
{
eval the code from the plugin file, passing it
the data from inside the tag and any attribute
values
place the $result back into the document
in the place of the original tag&data
}
}
}
My implemention is very naive! I'm sure that in a single scan/pass over the document it could be run/compiled whatever, however my version scans over the doc many times and the processing overhead grows rapidly with each extra tag / nesting level present (bad, very bad).
Look... I didn't know that 0.04 seconds was a bad render time until recently, I thought I was doing quite well with it, the code I have is ROCK solid, the forum system I linked to earlier has been online for months without problems or resets and it runs on a box which cost $20 / month. If I used a 32 core processor dedicated box, I could just brute force process my performance problems out of the way, but I am trying to do two things by coming here with this:
1) share what I have because I am sure people will like it when they get it
2) garner support and insight in how to compile and process such a syntax in a more efficient manner than multi-passing regexes and evals, so that the solution will scale nicely to larger sizes without needing a server the size of jupiter.
| [reply]
[d/l]
[select] |
If you want to attract people to your framework, you will have to win them over from the framework they are currently using. I would recommend that you either implement and showcase the existing demo programs from other frameworks, or come up with your own showcase demonstrations and discuss how the implementation in your framework compares to other implementations. See for example
- Pitting Mojo vs Dancer in a competition to build Top100 2.0
- Mojo vs Dancer Week 1 - Installer, Support and Hello World
- Mojo vs Dancer Week 2 - Templates and Images
Most people in your audience likely already have a way of producing web content, and most of them are familiar with Perl, so you will need to convince them that foregoing Perl in favour of another language, equally powerful but with a different syntax has benefits. Also, you will need to show where the customization interfaces are for your framework.
| [reply] |