Where do I put my libraries ? template folder ?

[Doc]

Hi,

I'm making my first steps with PW, as a training session I'm rewriting an old website -> PW.

I used to have a 'lib' directory where I put stuff to include to my php pages (connection file, general application info, etc.), what is the best practice here ?

Include that stuff in _general_app_info.php, _other_stuff_to_include.php,...  in the template directory ?

Thanks

[alxndre]

I don't know if it's the best practice, but i normally just organize all the files inside the templates folder since it's easier when you import/export site profiles because they get included. My normal file structure looks like this:

I place all 3rd party plugins (jquery, bootstrap plugins, etc) under the vendor folder. I also use a somewhat MVC (not strictly) approach, so I place all my controller files in functions folder, and all my views in views folder. You get the idea. I hope this helps.

[Doc]

Thanks for the feedback @Alxndre'

[owzim]

Every site I build has an own module, where I put all my hooks and additional logic. Also I use an autoloader there to load all the custom classes. They reside in a psr-0 structure within the modules directory.

Anyway, I would not recommend using class calls within your templates, rather encapsulate all logic/data needed by the templates in module properties/methods.

Perhaps the TemplateDataProviders module might interest you.

[Doc]

Thanks for your input @owzim, I'm not sure that module is still compliant with PW 3.x but I'm going to see what it proposes (http://modules.processwire.com/modules/template-data-providers/).

[FrancisChung]

50 minutes ago, owzim said:

Every site I build has an own module, where I put all my hooks and additional logic. Also I use an autoloader there to load all the custom classes. They reside in a psr-0 structure within the modules directory.

Anyway, I would not recommend using class calls within your templates, rather encapsulate all logic/data needed by the templates in module properties/methods.

Perhaps the TemplateDataProviders module might interest you.

Hi @owzim,

What is the reason behind not recommending using class calls (and presumably classes) within your templates? Is it a performance thing? 

I've actually built a site using classes , and coming from a OO Background I can't see myself going back to Modules / Procedures now .... easily ...

[owzim]

@FrancisChung good question.

Any business logic should be separated from the view layer. A template is a view, code there should not be complex. Loops, perhaps some string concatenations, value calls, nothing more.

You want a template designer not to fiddle with your code and perhaps even break something. Even if you are the template designer.

For complex logic use Modules, Template Data Providers or something like the Controller/View separation used in Template Engine Factory

I understand that this is perhaps not the ProcessWire way, right out of the box, or at least not something that is advocated too much, but I think it's because ProcessWire does not dictate how you use it. MVC ... or just VC in this case is just one way to do it. For simple sites perhaps overkill but if your code grows more complex, the VC concept makes the project more sustainable and it's a well established concept.

[FrancisChung]

Ah MVC ... 

Whilst I didn't strictly use any of the MVC/MVP/MVVM etc methodolgy for this project (I felt the complexity > benefits), I did seperate the business logic and  UI Logic/ controller sometimes if it was beneficial.

It didn't make sense for me to fully apply the usual SW Engineering methodology for a simple content based website with running on Processwire.

Good to know there's some Modules like Template Data Providers and Template Engine Factory out there for future iterations.

[owzim]

Just to clarify, when I say "no complex code in your templates" I actually mean no complex code mingled with your html (xml, json or whatever your output is). In the case of TEF your templates act as controllers, hence can have complex code, but the views are separated.

You don't even need a module to implement this methodology

Here's a post by @teppo with an example hwo to do it with the tools included in PW core:

 

[blynx]

My few cents:

I recently began to make a clearer distinction between the templates folder and the site folder.

So anything in templates shall just be real "templates" and related stuff for the frontend. Though the template files function as controllers. But well, thats processwire ...

In site/ I now have vendor/ with composer packages—because they are no templates, of course—and include them in site/init.php. There is also a /site/functions.php ... my own 'classes' become processwire modules.

In templates:

php related:

/fields
/components (like fields but with some extra functionality ... work in progress ... anything can be here. parts, snippets, head, partials, js css and php is bundled and provided together)
/emails (html email templates to render maybe)
/padloper (if I use padloper)
/layouts (main "framing" templates for delayed output method)
/forms (some custom forms?)

other

/scripts
/styles
/...

Edit:

If you are new, you might want to check out this blog entry about site/init.php or site/ready.php ...

https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/

Huh, I am recommending the same blog entries all the time - but they really helped me structuring my processwire sites. (It's nice to rely on processwires own ways - like a best practice built in .... or so .... whatever ....)

[LostKobrakai]

For composers vendor folder I'd suggest putting it into the root folder. PW 3.0 does auto include from there and it's basically all the dependencies the site has which is kinda like the wire folder as well. 

[AndreasWeinzierl]

Could somehow help me?

I added my vendor folder in the root directory.

And I supplemented my composer.json by a library from github:

{
  "repositories": {
    "pwRest": {
      "type": "package",
      "package": {
        "name": "NinjasCL-archive/pw-rest",
        "version": "1.3.0",
        "source": {
          "url": "https://github.com/NinjasCL-archive/pw-rest",
          "type": "git",
          "reference": "master"
        }
      }
    }
  },
  "name": "processwire/processwire",
  "type": "library",
  "description": "ProcessWire CMS/CMF",
  "keywords": [
    "processwire",
    "cms",
    "cmf",
    "content management system"
  ],
  "license": "MPL-2.0",
  "homepage": "https://processwire.com",
  "authors": [
    {
      "name": "Ryan Cramer",
      "email": "ryan@processwire.com",
      "homepage": "https://processwire.com",
      "role": "Developer"
    }
  ],
  "require": {
    "php": ">=5.3.8",
    "ext-gd": "*",
    "NinjasCL-archive/pw-rest": "1.3.*"
  },
  "autoload": {
    "psr-4": {
      "restApi\\":"vendor/NinjasCL-archive/pw-rest/rest/core"
    },
    "files": [
      "wire/core/ProcessWire.php"
    ]
  }
}

Compose install does work without any problems, but if I try to use autoloading it does not work as wished. 

Within the templates folder I try to instantiate RestApi\Response or \restApi\Response, but I always get the following error: 

Error: 	Uncaught Error: Class 'RestApi\Response' not found in phpFile.php:12 
Stack trace: 
#0 www\wire\core\TemplateFile.php(287): require() 
#1 www\wire\core\Wire.php(380): ProcessWire\TemplateFile->___render() 
#2 www\wire\core\WireHooks.php(723): ProcessWire\Wire->_callMethod('___render', Array) 
#3 www\wire\core\Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) 
#4 www\wire\modules\PageRender.module(514): ProcessWire\Wire->__call('render', Array) 
#5 www\wire\core\Wire.php(383): Proce (line 12 of phpFile.php)

BTW. The response class is in 

"vendor/NinjasCL-archive/pw-rest/rest/core/response.php"

[AndreasWeinzierl]

    "classmap": [
      "vendor/NinjasCL-archive/pw-rest/rest/core/",
      "vendor/NinjasCL-archive/pw-rest/rest/languages/",
      "vendor/NinjasCL-archive/pw-rest/rest/login/"
    ],

With this I finally got it working after quite a few hours.