Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dragooon
646
Off-topic / Pre-made CSS/HTML framework?
« on September 28th, 2011, 04:05 PM »
I, in as many words, am a very very terrible designer. Does anyone know a good CSS framework with, preferably, an orange color base that can be used to make full fledged websites? Half decent IE6 compatibility is kind of required.
647
Plugins / Re: Hooking up data loading
« on September 27th, 2011, 06:49 PM »
I'll add some traditional getters and setters for emergency reasons only, if required an add-on author can do some checks of his own. Most of the time it's generally a new field in SELECT anyway.
648
Features / Re: New revs - Public comments
« on September 27th, 2011, 06:12 PM »
There are 7 instances of plugin in ManageAddons.php :p
649
Plugins / Re: Hooking up data loading
« on September 27th, 2011, 01:41 PM »
Yeah I realised that a few minutes after I posted my reply. There are, potentially, 2 ways to resolve this that I can think of

1) Parametrize all the constructs instead of just SQL statements, that way we can match or equalities
2) Do some string operations/regex operations. Extract table and alias and match them against any other one.

We can always pass this information to add-ons if we can get that out, although I doubt add-ons will really implement a set of if/elses.
First option restricts down SQL quite a bit. Second one is unreliable.
650
Plugins / Re: Hooking up data loading
« on September 27th, 2011, 01:29 PM »
I don't think there's a good way to avoid multi binding, and upon testing the developer would probably get the error and fix it so I don't see much of a problem anyway.
651
Plugins / Re: Hooking up data loading
« on September 27th, 2011, 11:50 AM »
I've updated the first post with latest Class-DBQuery.php along with some documentations. Feedback is appreciated :).
652
Features / Re: Standardization of UI elements
« on September 26th, 2011, 05:50 PM »
Quick moderation are not pure forms so I didn't count them.
653
Features / Re: Standardization of UI elements
« on September 26th, 2011, 04:31 PM »
I'd go with each element with different class option, it is more fitting plus having one function for all is a bloody mess. The classes will only be responsible for rendering the element's HTML, the main form class would be responsible for taking the rendered HTML and placing it inside it's containers/calling templates.
Quote
I don't really see many themes actually changing that but if it's done appropriately with CSS it shouldn't be a problem - and it's not as if a page expressly has to use that (cf Post page, Display's quick reply, quick moderation, these are all forms I might validate with the generic handler but not use it for rendering)
More than themes I'm concerned about mods that might need to do something. As far as post page goes, I don't think it's that out of the form's league since I did most of my thinking keeping it in mind. The HTML can be rendered with form class along with the javascript outputted via Post.template.
654
Features / Re: Standardization of UI elements
« on September 26th, 2011, 03:55 PM »
Been thinking on how to go about the forms, and it seems something similar to Zend(Not Zend itself) but without such complex decorators would be the best option. We don't need such complex decorators because most of it would be handled by theme, plus most of the forms contain more or less the same dt/dd combination of fields surrounded in a fieldset(Which can most likely be modified since one should be able to change the template functions of the form in order to maintain extensibility). Most of the UI customizations seem to be a result of change in CSS rather than HTML so that's even better.
655
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 12:47 PM »
What do the rest think about it? Especially the query builder example I posted on previous page.
656
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 12:29 PM »
Quote from Arantor on September 26th, 2011, 12:25 PM
That's the thing; I don't especially want to expand the validation at point of general query, but I would do so happily at the point of data insertion.
Fair enough, no one needs to.
657
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 12:19 PM »
Quote from Arantor on September 26th, 2011, 12:10 PM
I'm pretty enthusiastic about validation at the best of times, but it's not often that we do selects or similar that need anything other than int, string, or an array of ints or strings. Might I suggest, then, that we do that validation in the insertion routine instead?

It's also a performance thing: I'm not enthusiastic about making the process of physically querying any slower than it needs to be, and already there's a significant overhead vs a bare mysql_query call. It isn't a killer because we rarely make beyond 15 queries per page but it is something to bear in mind.
In the end insertion is also validated at the same place any other query is, and they follow the same int, string, array_int etc ruleset. What I originally said was that expanding these rulesets is much easier than before as now new data types can be declared outside of source.
658
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 11:50 AM »
Yeah, as that can help validation. Currently it'll require modification to source and adding a new case under the callback function in wesql class, whereas wesqlQuery would just require a declaration of a new class called wesqlParam_email which can contain the validation and formatting functions required.

Something I'm still thinking about is the parameter syntax, I changed it so that the data type is declared at the PHP code instead of SQL(Query builder in this case), you think I should keep it the old way?
659
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 11:28 AM »
Quote from Arantor on September 26th, 2011, 11:18 AM
I don't think the syntax needs to change at all (to be honest I'm not sure what else you could do with it anyway) and as for ease of use, I can't see any comparable way of making big queries extensible - it's harder to use than a bare query, until you're used to it, but it's extensible in a way that bare queries aren't.
Thanks, I've been trying to keep the syntax as simple as possible.
Quote from Arantor on September 26th, 2011, 11:18 AM
And since I don't envisage most add-ons having to write them I doubt it'll be a problem, provided there is sufficient documentation and examples of using said setup to extend queries.
I believe only some major add-ons would like to use those queries in some major part, but even then that'd be rare. Using the hooks to extend existing queries would be a lot more common, especially around loadMemberData, Display and a few other areas. Still, providing documentation won't be hard for this. I've tried to keep the structure logical and easy to understand. Plus it offers the ability to declare custom data types(Something which should be backported to traditional queries honestly).
660
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 11:11 AM »
What do you think of the syntax, ease of use etc?