Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
PHamlP Integration?
  • Could someone roughly explain the best approach to integrating PHamlP (http://code.google.com/p/phamlp/) into Fuel? I am new to this framework and could use a nudge in the right direction.
  • Well, I got Jade working with the Parser package, based off of a Jade for Kohana fork I found (https://github.com/jeremyf76/jade.ko3) I will clean up and post my code tomorrow. With regard to the Parser package. Should the Jade classes and source go in /app/packages/parser/vendor/jade or /app/vendor/jade ? In Parser's configuration file (/parser/config/parser.php) it implies both are options**, but I am unsure how to decide when one way is more appropriate over the other. I could not find a satisfying explanation anywhere, so I assume this might be something that will be standardized in future revisions? ** Here are the relevant snippets that leave me scratching my head a little: PKGPATH . 'parser' . DS . 'vendor' . DS . 'jade' or APPPATH . 'vendor' . DS . 'jade'
  • Take a look on Parser documentation :
    "While many other drivers are included, their libraries are not and are by default expected in app/vendor/lib_name (capitalize lib_name), you'll have to download them yourself" So, jade library goes to "app/vendor/Jade" <-- "Jade" not "jade" ( library folder name must be capitalized for standards ) For second question, use :
    APPPATH . 'vendor' . DS . 'Jade' . DS . 'JADE AUTOLOADER' Excluding SimpleTags ... all other libraries go to app/vendor folder
  • Thanks for clarifying. It seemed confusing enough to double check and make sure the manual's author had indeed intended it that way. Perhaps to remove confusion it would be a good idea to add a note in the README that restates what you just said: excluding SimpleTags, all other libraries go to app/vendor folder
  • There are some small changes that need to be made. I know Jelmer has not pulled the jade parser code yet so I thought I'd just post it here. There are a bunch of errors like this in log file: Error - 2011-06-24 16:11:37 --> 2048 - Non-static method Parser\View_Jade::cache_init() should not be called statically in /Users/calvinfroedge/htdocs/froedge/fmslumberhandling/code/fuel/packages/parser/classes/view/jade.php on line 34 Changing... public function parser() and public function cache_init($file_path) To... public static function parser() public static function cache_init($file_path) Resolves these errors. Since methods are referred to statically, they should be defined as static.
  • Just read https://twitter.com/#!/fuelphp/status/81011081081929728 I have Jade working within Parser. Basically, re-purposed Jeremy Fowler's Kohana module code (https://github.com/jeremyf76/jade.ko3/blob/kohana3/classes/jade/core.php) to act as the Jade_View class (/parser/classes/view/jade.php) and used Konstantin Kudryashov's Jade PHP implementation (https://github.com/everzet/jade.php) as the library with an autoloader to get the Lexer + Dumper + Filter stuff added to the namespace. However, there's a debate in my office regarding how best to integrate with Parser. Should it remain as I describe above, or should a stand-alone Jade package be created that extends Parser? The existence of the various view classes (/packages/parser/classes/view/*.php) implies that I'm doing it correctly, but I wanted to make sure because the instructions on installing new parsers (https://github.com/fuel/parser/blob/develop/README.md) isn't real explicit about this. Plus it's unclear if there might be issues (copyright or convention or cleanliness) with bundling these things altogether.
  • Evan Tishuk wrote on Wednesday 15th of June 2011:
    However, there's a debate in my office regarding how best to integrate with Parser. Should it remain as I describe above, or should a stand-alone Jade package be created that extends Parser? The existence of the various view classes (/packages/parser/classes/view/*.php) implies that I'm doing it correctly, but I wanted to make sure because the instructions on installing new parsers (https://github.com/fuel/parser/blob/develop/README.md) isn't real explicit about this. Plus it's unclear if there might be issues (copyright or convention or cleanliness) with bundling these things altogether.

    Personally I think that create a Jade driver for Parser package is the right way. I've checked the licence of libraries you have linked :
    https://github.com/jeremyf76/jade.ko3/blob/kohana3/LICENSE
    https://github.com/everzet/jade.php/blob/master/LICENSE And all uses a MIT License ... the license is the same of Fuel ( http://fuelphp.com/docs/license.html )
    So I think there isn't any problem. Why you don't fork Parser project and commit your work?
    Someone can take a look on your code and can help you
  • Davide Bellini wrote on Wednesday 15th of June 2011:
    Why you don't fork Parser project and commit your work? Someone can take a look on your code and can help you

    Great question. Here you go: https://github.com/evantishuk/parser
  • Davide Bellini wrote on Wednesday 15th of June 2011:
    Personally I think that create a Jade driver for Parser package is the right way.

    Good to know. I wonder if there's a good way to avoid the need to put an autoloader into the library? Would be nice to just wget and edit some configs. I guess that's how oil is intended to be used?
    Davide Bellini wrote on Wednesday 15th of June 2011:
    I've checked the licence of libraries you have linked :
    https://github.com/jeremyf76/jade.ko3/blob/kohana3/LICENSE
    https://github.com/everzet/jade.php/blob/master/LICENSE And all uses a MIT License ... the license is the same of Fuel ( http://fuelphp.com/docs/license.html )
    So I think there isn't any problem.

    Thanks, I also don't think there would be a copyright problem, but it seems like some of the Kohana people are/were a little chippy (http://forum.kohanaframework.org/discussion/7790/fuelphp-what-can-we-learn-from-its/p1), so I definitely don't want to step on any toes. Also, thanks for the comments on the code I pushed. I am curious if you (or anyone else) has had success getting Jade to function on other systems. I am about to start a sizable project that will take advantage of Jade, so hopefully this package will come in handy. I anticipate being able to speak a little more confidently about its benefits and usage after getting my hands more dirty.
  • Evan Tishuk wrote on Thursday 16th of June 2011:
    I wonder if there's a good way to avoid the need to put an autoloader into the library? Would be nice to just wget and edit some configs.

    Well, whatdoyouknow. My system originally had complained when I used the built-in autoloader (autoload.php.dist) that comes with the Jade PHP library (https://github.com/everzet/jade.php). Apparently, I was doing something else wrong. So, no need to re-invent that at all--just add the path to autoloader.php.dist in Parser's config, and viola. I went ahead and pruned all the functions that weren't necessary: https://github.com/evantishuk/parser/blob/develop/classes/view/jade.php Appears to work swimmingly.
  • Thanks for your work on this. Question: 1. I have Jade directory created under fuel/app/vendor/ with the original Jadephp files in it (from https://github.com/everzet/jade.php)
    2. I have jade.php in /packages/parser/classes/view/jade.php
    3. I have added config to include: 'jade' => 'View_Jade', AND.... 'View_Jade' => array(
    'include' => APPPATH.'vendor'.DS.'Jade'.DS.'autoload.php.dist',
    ), 4. I use this in my controller ('parser' class is auto loaded): $this->response->body = View::factory('welcome.jade'); No dice. ErrorException [ Error ]: Class 'View_Jade' not found Any idea what I'm missing?
  • Calvin Froedge wrote on Friday 17th of June 2011:
    No dice. ErrorException [ Error ]: Class 'View_Jade' not found. Any idea what I'm missing?

    If you're piecing it all together rather than downloading the whole package from my repo (https://github.com/evantishuk/parser), you'll need to make sure to edit /packages/parser/bootstrap.php to include:
    'Parser\\View_Jade'        => __DIR__.'/classes/view/jade.php',
    

    If that doesn't fix it, I would suggest downloading the entire parser package from my repo -- it's should work as-is.
  • Hey, man. That did it. Beautiful work. Let me know your PayPal and I'll buy you a beer.
  • I forked evantish's repo on Github and made a few improvements. Mainly, the code is just simpler now - less like the Kohana driver and more in line with the other drivers in the package. Also, Jade will now cache the compiled templates in the app/cache/jade directory. https://github.com/evantishuk/parser/pull/1
  • Nice, Rick. That's definitely a big improvement. You sliced about half the code out, added caching and fixed the name collision problem, in one fell swoop. I owe you a beer too = )
  • AAAND.... this thread has come full circle: PhamlP now works with Parser: https://github.com/evantishuk/parser (if you're into that sort of thing). Here's the library to use http://code.google.com/p/phamlp/downloads/list Also, I messaged everzet (https://github.com/everzet/jade.php) about Jade PHP -- specifically if he was planning to continue work on it -- and he said he's jumping back on it late June early July after the christening of Behat 2.0. For some reason, I feel like this is appropriate to how I feel: http://www.youtube.com/watch?v=qjazkgtcrms
  • If your code works, please make a "Pull Request" from Github ... so Jelmer can check and merge your code into the official package.
  • Have you heard of Jade or Stylus? They were created by Learn Boost for node.js. They are similar to Haml/Sass but in my opinion much more elegant. Out of curiosity, you might want to check them out: http://www.screenr.com/bNY http://www.screenr.com/CV0 I can't give you too many pointers on how to implement in Fuel, but these github repos may give you some guidance if you're set on phpamlp: https://github.com/d4rky-pl/phamlp
    https://github.com/MarcWeber/phamlp
  • I hadn't considered using Jade, but you're right that is probably a better direction. Especially with the Jade template compiler for PHP: https://github.com/everzet/jade.php Still curious how feasible it would be to wedge this compiler into Fuel. And where to start. Or if I should just back away slowly and let the core development team take it under consideration.
  • Oh, snap. Didn't know someone wrote a jade compiler for PHP. Now you've got me motivated = )
  • Okay, so, should this be a module or a package?
  • As this is about 'core' code, and not about user facing code, it should be a package.
  • And this has been staring me in the face the whole time: https://github.com/fuel/parser
  • The parser package is a skeleton (in the works!) in which you can plugin multiple template parsers. If you're going to build a package, it would be handy to make it compatible with the Fuel parser.
  • Took a little doing to get the parse working -- got confusing with which vendor folder to put the libraries in -- until I looked in the parser.php driver and realized where it was looking for the code. That bit of documentation should probably be made more explicit. I'll try to get Jade working through Parser today and maybe PHamlP too. Will post results.
  • I'm working on Parser library for testing, better documentation, vendor folder name standards and a more complete configuration. Also fixing some problems with View::factory('module::viewname') method introduced in RC3. Keep us updated on your work progess...

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion