Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
1
Development blog / Re: This. Is. Crazy.
« le 4 Avril 2012 à 00:00 »
Nao, Arantor, congratulations. I have thoroughly enjoyed seeing your progress and I am extremely happy that an open source license has made this possible. You guys have worked your asses off and it shows. Keep up the good great work!
3
Features / Re: Fixing mismatched BBCode
« le 27 Décembre 2011 à 04:21 »Okay, I'll look into doing that tomorrow...
Still, complex errors won't be magically fixed, I'm afraid... Unless, unless I do a stricter check.
So while typing this post, it came to me that I could use a stack of tags and stack/unstack data and... Well, have a look at this code:Code: [Sélectionner] [/quote][quote author=Nao link=msg=1 date=1309111289]Lorem ipsum?[/quote]What is that?
I don't speak rubbish!
[nb]I'm wondering if Rory does, though? He had time to learn...[ /code]
[ code][ nb][ /code][ /nb]
And... Here's the error message I'm getting following my latest rewrite. Which is actually SHORTER than the last one ;) It's not perfect but I'm working on it eheh.
Pretty cool uh?
PS: and yes, it works with tag nesting too, since it's a stack... i.e. if I have properly nested 'b' tags inside the quote, everything's fine.
PPS: the main issue with fixing tags in the middle of a message is that I would then have to find the exact position of the tag... I guess it's doable, though, but I'll have to go through a series of strpos etc or something to fill in the list first, so it'll definitely make the code bigger.
4
Features: Theming / Re: JavaScript caching
« le 4 Juillet 2011 à 16:21 »
I think minification is more about saving space in the cache. Especially for mobile devices.
5
Features: Forward thinking / Re: Code clean-up
« le 3 Juillet 2011 à 17:50 »
It is slower no matter what.
6
Features: Forward thinking / Re: Objects
« le 3 Juillet 2011 à 17:49 »
In SMF you'd assign it to another variable. With a singleton you'd need another class.
Dragoon, like PHP, where you have that last parameter for the resource, you should have the ability to select the resource or use a default one. There's many good reasons for using different databases.
I'm not knocking using OOP over a global variable, but you should use what's right. So, instead of $result = we::query('SELECT * FROM some_table') consider $result = new weQuery('SELECT * FROM some_table');
It works the same but you have more ability. You then put a whole bunch more ability on to that: statements, fetching on the object, etc.
Dragoon, like PHP, where you have that last parameter for the resource, you should have the ability to select the resource or use a default one. There's many good reasons for using different databases.
I'm not knocking using OOP over a global variable, but you should use what's right. So, instead of $result = we::query('SELECT * FROM some_table') consider $result = new weQuery('SELECT * FROM some_table');
It works the same but you have more ability. You then put a whole bunch more ability on to that: statements, fetching on the object, etc.
7
Features: Forward thinking / Re: Code clean-up
« le 3 Juillet 2011 à 05:52 »Mainly on things like ini_get and so on if I remember right. I'm sure, though, that Amdahl's Law is also applicable here...
8
Features: Forward thinking / Re: Objects
« le 3 Juillet 2011 à 05:50 »
It is the same in the sense that it isn't object oriented. If all you're using a class for is a function wrapper, use namespaces.
Each query and each connection should be a separate object... because they are. Now, since you have all static methods, how would you work it if you wanted to have multiple connections? No clue how you are working queries, but what if you wanted to run a query in two places at the same time? You're going to have issues with coupling.
The query_see_topic and query_see_ticket stuff should probably be a method of that class. In reality, you should just worry about normalizing that table.
Each query and each connection should be a separate object... because they are. Now, since you have all static methods, how would you work it if you wanted to have multiple connections? No clue how you are working queries, but what if you wanted to run a query in two places at the same time? You're going to have issues with coupling.
The query_see_topic and query_see_ticket stuff should probably be a method of that class. In reality, you should just worry about normalizing that table.
9
Features: Theming / Re: JavaScript caching
« le 3 Juillet 2011 à 05:44 »
Dragoon, although I wish you would have asked me before quoting that, it is my post and I don't mind (for that one).
Arantor, yeah, that one.
Arantor, yeah, that one.
10
Development blog / Re: New directions
« le 2 Juillet 2011 à 20:34 »Ask them to do so, then. We were fine until one of the team decided to throw their not-well-informed opinion over here.
11
Features: Forward thinking / Re: Code clean-up
« le 2 Juillet 2011 à 19:52 »
Glad to see that. Hopefully you can get rid of some of the big ones like the over use of @ operator
12
Features: Forward thinking / Re: Objects
« le 2 Juillet 2011 à 19:49 »
Why are you using a singleton for a query? Using singletons everywhere is the same as using procedural.
13
Features: Theming / Re: JavaScript caching
« le 2 Juillet 2011 à 19:47 »
I was just going over some old notes and saw this: http://www.simplemachines.org/community/index.php?topic=391132.msg2981869#msg2981869 and then I went here and saw this.
14
Off-topic / Re: Unknown's thoughts on Wedge
« le 29 Juin 2011 à 03:55 »
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)
15
Off-topic / Re: Unknown's thoughts on Wedge
« le 27 Juin 2011 à 15:25 »
I need to bookmark this for later read.