phpQuery and Views

[eluser]ntheorist[/eluser]
i also just stumbled upon phpQuery and wondered if anyone had tried to integrate it with CI. I'm a die hard jQuery fan so it did seem exciting, but yeah its hard to fathom having to sort through an extensive documentation (even though its constructs are very similar to jquery), plus adding queryTemplates seems like a natural fit with it, but again, that's a whole nother monster library/api to learn and memorize.

whatever happened to $this->load->view('file/path', $data, TRUE)?.. it seems crazy to walk away from something so simple..

[eluser]Gerson[/eluser]
I don't think using queryTemplates (read here phpQuery) would be any easier than just $this->load-view. But the point here isn't it. The beauty in use queryTemplates would be the possibility to have strict and untouched HTML files as templates for a complete separation of system logic and data presentation. It's like build (when you want it) a (good and desired) "Berlin wall" between programmers and designers' work, creating an ideal scenario where Designers don't mess the logic code and programmers don't break the layout...

PS: Excuse me the comparison with such a bad history, maybe it would be better to use "The Great Wall of China"? Well... You got the idea.

[eluser]ntheorist[/eluser]
i do understand the logic behind separating views from code, and thus designers from programmers. Typically most people use 'template logic' to remove actual php from a view, but its STILL logic, and both sides would still have to agree on a syntax to use.

I'm not sure if i understand it correctly yet, but it seems phpQuery searches for a specific element/id/class in the xhtml and inserts/manipulates the data without a need for {pseudo_variable} to be in the view. The only problem then is if the designer changes the class names/ids or nests the ul > li somewhere else or pushes it deeper in the DOM, wouldn't that break many instances of the business logic? In any case both sides still have to agree on a context to use. Designers would still need some sort of assistance (berlin air lift?) and programmers would need to be schooled on the layout anyway.

n

[eluser]slowgary[/eluser]
This is just my opinion (and I'm ALWAYS wrong), but it seems a little tough to imagine that developers writing PHP (which is 99% web-based), don't have at least a basic understanding of (X)HTML - the language of the web. In the same vein, if you're a designer who's using PhotoShop and also understands enough to slice your designs to valid XHTML & CSS - is learning to use a template variable really so {HARD}?

I've never heard of phpQuery myself, but all these solutions seem like a lot of overhead to save someone from, GHASP - LEARNING SOMETHING.

[eluser]ntheorist[/eluser]
heh i would have to say you are not wrong there. Much of php is in fact, dynamically writing xhtml. It's not that programmers don't understand xhtml, its that many programmers aren't designers.. Case in point - look at phpclasses.org, one of the richest sources of php scripts on the web, and it is UUUUUUUGLLY! Being able to design as well as program is quite an advantage, imo, and anyone with a modicum of interest in web development SHOULD be able to pick up skills on both sides, and most do to some extent, i would guess.

The only excuse i could see for complete separation is if you had a dedicated team of people with very specific roles on a large development project. I guess i'm a php purist at heart, so it seems ridiculous to add an abstract layer with a whole new lexicon of functions to learn, even if it ends up being more convenient.

still, it would be nice to have a slick jQuery api, to add ready statements and apply dynamic options to plugins as you please, etc.. Some of that could be achieved by loading data to 'javascript' views.

I actually made a single ready() function that i use a lot now. I use it during development in my views,controllers etc., whereever i like. and its pretty much just $this->ready('selector','functionname','function() { jquery code ... }); i can use it all over the place and it combines all of it into one $(document).ready() when the page is sent to browser - which i could copy paste later in a file during production for cleanup. It stores everything in one array $ready[{selector}][{functionname}] = {function code}, so it prevents duplication and allows for further optimizing/organizing possibilities on page load.

n

[eluser]TheFuzzy0ne[/eluser]
Interesting discussion. I know where you're coming from, since I can write perfectly valid (X)HTML, and perfectly valid CSS, but still end up with a f'ugly site. I seem to have virtually no colour sense, and it saddens me.

I too, would have used phpclasses.org as an example. It's a prime example of how content can sell a site just as much as graphical design can.

I've always wondered - if a PHP developer like me can write valid (X)HTML, how hard would it be for a designer to learn how to echo a variable, and some simple PHP logic? After all, they've learnt how to use the parser syntax, why not learn a little PHP logic syntax instead?

In case you haven't guessed, I'd rather avoid the overhead of a template parser when possible.

[eluser]ntheorist[/eluser]
the funny thing is, many tempalate engines mainly emulate php in their templates (cough, cough.. smarty) so if a designer can write {if $edit_flag} xhtml.. {/if}, you'd rightfully expect them to be able to write <?php if($edit_flag) { ?> xhtml... <?php } ?> conventions can be hard to break though.

I'm attracted to the {} syntax because it cleans up code, and more importantly at the moment, tinyMCE wont strip it like it does php tags, plus it can be passed around as strings from place to place without corrupting any php code that may be executing it.

yeah i do love phpclasses, but i can honestly say i would prolly spend more time there and discover more if it were a better user experience. As far as finding full fledged scripts for whatever you can think of tho, it's hard to beat.

as far as having no color sense, i wouldn't doubt yourself too much. many successful designs employ color schemes based on very basic color theory. it's worth a read at wkp.. there is so much else tho, composition, spacing, contrast, imagery font size etc.. I usually start with a basic color idea and work up from there. And if i need inspiration i'll search for good css designs or look at award sites like netdiver or thefwa.com

n