module Wireframe

[Craig]

  On 8/22/2020 at 7:36 AM, bernhard said:

What if I have some piece of code that is needed on several templates (controllers are out) that has some business logic?

Expand  

I use Utility Classes in these cases ?

Or you could maybe use PHP traits and use them in the controller classes?

[bernhard]

Thx @Craig I did read about them and then forgot that they exist ? Sounds like a good usecase for them! So I'd build a utility class "LocalTime" and then call LocalTime::local("d.m.Y H:i:s")? Sounds like a good solution!

[Craig]

Something like that, yes! Use it in controllers and/or components as and when you need to ? 

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

I also like to use these for getting pages for sections of the site that are repeated in different places - like news or events - and have functions like findRecent() or findByCategory(), which can accept parameters for limit, category, etc. These can then be used on homepages, sidebars, main news/events pages, or RSS. The functions interpret the parameters, set some defaults (parent, template), and make some pages()->find() calls to return the requested pages.

[bernhard]

  On 8/22/2020 at 5:52 PM, Craig said:

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

Expand  

Yeah, but that sounds like a good usecase for a regular PW module as this could likely also be useful for other projects ? 

[Craig]

  On 8/22/2020 at 6:10 PM, bernhard said:

that sounds like a good usecase for a regular PW module

Expand  

Like RockDatetime? ? Yeah - if it's mostly site-specific, I'd put it in a utility class. Multiple sites - probably a module ? 

[teppo]

Heads-up! Wireframe 0.12.0 is now the latest master version. This is a pretty big update (in both lines of code, as well as features), so I'd recommend testing carefully after updating. The biggest parts are implemented as a companion module Wireframe API, but there are quite a few changes and updates for the main module as well:

### Added
- Support for named arguments when using `Wireframe::component($component_name, $args)`.
- JSON API. See comments in the WireframeAPI module file for more details.
- New Page methods Page::getController() and Page::setController().
- Module config screen provides support for creating directories corresponding to configured Wireframe URLs, assuming that they were provided as relative paths.

### Changed
- Wireframe::setView() accepts optional view name as an argument.
- View::setController() accepts Controller name (string) in addition to Controller class instance or null.
- When Controller is instantiated, it no longer overrides the Controller property of the related View instance.

### Fixed
- Wireframe::partial() now works as expected for partial names with file ext included (partial_name.php etc.)
- Wireframe::partial() prevents 2 or more dots in partial name, just in case (directory traversal is not intended).

 

[bernhard]

@teppo just a short heads-up ?

I'm building my new design mostly of components. The homepage view looks like this:

<?php namespace ProcessWire;
echo Wireframe::component("Header");
echo Wireframe::component("Search");
echo Wireframe::component("Slider");
echo Wireframe::component("Welcome");
echo Wireframe::component("Visions");
echo Wireframe::component("News");
echo Wireframe::component("Quotes");
echo Wireframe::component("Newsletter");
echo Wireframe::component("Partner");
echo Wireframe::component("Footer");

This is pseudocode of the Welcome component:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  public function __construct() {
    $this->setBg();
    $this->setEmblem();
  }
  private function setBg() {
    $this->bg = null;
    try {
      $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
      $img = $item->get(Slideritem::field_img);
      $this->bg = $item->imgUrl($img);
    } catch (\Throwable $th) {
      $this->log($th->getMessage());
    }
  }

  private function setEmblem() {
    $this->emblem = null;
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    $this->emblem = "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

Maybe they could even do a try catch automatically and log the error silently on production and throw an exception on dev?

The component would then become a lot cleaner:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  
  public function getBg() {
    $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
    $img = $item->get(Slideritem::field_img);
    return $item->imgUrl($img);
  }

  public function getEmblem() {
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    return "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

Thx

[teppo]

Hey @bernhard!

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view? If so, I'll be sure to dedicate this some thought soon, and if it does indeed seem like a good idea, I'll try to get it implemented for the next release (after 0.13.0, which went live a few minutes ago) ?

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

Anyway, this is just me thinking out loud. I'll see what I can do about this in the near future ?

I've added your idea about catching errors and logging them to my todo list. Not entirely sure about this one yet, but it's definitely worth thinking through.

[teppo]

Wireframe 0.13.0 went live a while ago.

This version introduces only one new feature: variables sent by controller to the view — as well as $partials and $placeholders — now work as-is while rendering fields (= in field templates). In previous versions these were accessible via the $view API variable, which didn't feel quite as intuitive. This required a new hook so there's a bit of added overhead, but at the same time various optimizations were made here and there, so this is unlikely to be noticeable.

One thing to note is that this version contains a few breaking changes, though I'd be a little surprised if they affected any real sites: some Wireframe methods were converted from public to protected (these were never really intended as part of the "public API"), and the first argument for Controller class constructor method is no longer an instance of ProcessWire (this wasn't actually necessary).

Here's the full changelog:

### Added
- New hook makes View properties directly accessible in TemplateFiles (e.g. when rendering field templates)

### Changed
- Wireframe::getController() is now a public method that can return current Controller instance, the Controller instance for provided page, or a Controller instance for provided Page and template name.
- Visibility of following methods was changed from public to protected: Wireframe::___checkRedirects(), Wireframe::___redirect(), Wireframe::___initView(), Wireframe::___initController(), \Wireframe\Config::getCreateDirectoriesField().
- Controller class implementation was streamlined: new objects are wired using the native wire() function, and thus Controller constructors no longer require the ProcessWire instance as an argument.
- Wireframe no longer caches partials unnecessarily, plus new Partial objects are automatically wired.
- Various minor optimizations, some code cleanup, and a few improvements to comments.

 

[bernhard]

  On 8/28/2020 at 11:31 AM, teppo said:

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view?

Expand  

Yes ? Just wanted to share my experience so far and point out that I still think it would be nice to have.

  On 8/28/2020 at 11:31 AM, teppo said:

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

Expand  

No idea about the complexity behind, so of course it's better to think twice ? Also no idea about Wireframes caching yet. I'll throw everything to ProCache in the end ? 

---

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left ? Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?! But even if that was one part of the "problem", the other part still remains: Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now ? 

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects ? 

[Ivan Gretsky]

  On 8/28/2020 at 12:53 PM, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now ? 

Expand  

As I get it, partials came first (there were no components at the time). And components were added later due to user requests. I think too that only one (the components)) should stay in the future. But I may be missing something.

[teppo]

  On 8/28/2020 at 12:53 PM, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now ? 

Expand  

I'm going to start from the end, because this is the easy part (maybe) ?

First of all, all the main concepts found from Wireframe have been around, in one form or another, for about a decade. Wireframe (the module) was developed a couple of years ago, and components were added about six months ago. Partials have been around since the very beginning, while components are a brand new thing.

As for "should there be both partials and components", this is a good question going forward:

• Components are more versatile, but also more complex. There's a class (for business logic) and one or more views (for markup).
• Partials are a lot simpler. Even though you can pass params to partials and arrange them in directories by type or whatever, they are essentially just individual include files.

In my typical project there's a need for both: by default I prefer the simplicity of partials, but if I really need to do something more complex on a per-element basis (justifying the mental and technical overhead of the class based approach), I go with a component instead. Heck, in one recent project I even surprised myself by using components within components. Not what I'd call an "easy to grasp setup" (which is always something that I try to emphasize in my work), but it gets the job done and was fun to work on.

Will components and partials eventually merge into one? I don't know — maybe, maybe not. For the time being I quite like having them both around. In my projects they tend to solve different problems, even though they could be used interchangeably ?

  On 8/28/2020 at 12:53 PM, bernhard said:

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?!

Expand  

Oh, I'm sure that this makes a huge difference!

As I've mentioned before I haven't really used custom Page classes, because — for my use cases — controllers provide same benefits, and then some more. Nevertheless, had custom page classes existed when I started working on Wireframe, there's a good chance that I would've taken an entirely different route ?

  On 8/28/2020 at 12:53 PM, bernhard said:

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left ? Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

Expand  

I might've already touched some of the same topics earlier — particularly the one about having more than one type of object in Wireframe — but a few additional notes on this:

• You don't have to use anything you don't need. Layouts, views, and controllers are all optional. In many of my projects there's one layout, a bunch of views (often much fewer than there are viewable templates, since many templates are so simple that the layout file takes care of all the markup), and a few controllers (just for those templates that require something "more complex" behind the scenes; news or event containers / lists, page search, etc.
• The "everything is a component" approach is quite possible with Wireframe, though that was never really something I intended (or expected, to be honest!) The roots of Wireframe are in the MVC architecture, and that's where controllers, view, and model (which in this case is actually ProcessWire) come in. Components were intended as something that you can use to "fill in the gaps"; a bit like utility classes, for that matter.

When you say that "Controllers are tied to the template of the viewed page", that's actually not entirely true: by default Wireframe will indeed only know that for a Page using the "basic-page" template it should check if a controller class called BasicPageController exists... but you can also make multiple pages share a single controller, change the controller on the fly, etc. Much of this is pretty new and I'm still experimenting with it, but I have high hopes that it will become even more useful in the future.

As for the "couldn't that also be handled by the component" part: controllers do certain things that components don't, there's always exactly one controller active for a specific page at any given time, and these two work in a different context. The context of a controller is a page render request, while the context of a component is much smaller — essentially the subset of the request that it has been provided with. In my opinion it's best to keep them as separate concepts — at least for the time being — though once again who knows what will happen in the future ?‍♂️

  On 8/28/2020 at 12:53 PM, bernhard said:

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects ? 

Expand  

I hope I don't really need to say this, but... feedback, comments, and (constructive) criticism is always welcome. I can't promise that I'll agree with all of it, but I'm happy to hear others' experiences nevertheless ??

--

I'm pretty sure that you've seen this already, but I've got a couple of site profiles online — https://github.com/wireframe-framework/site-wireframe-docs and https://github.com/wireframe-framework/site-wireframe-boilerplate. These are a bit dated by now (neither uses components, for an example), but they may provide some insight into the way I personally use Wireframe.

I've been really looking forward to revisiting the weekly.pw website and sharing that as well, hopefully something I can get done before the end of the year. This site is also really, really dated (both visually and feature wise), and I'd also like to show off some of the new stuff in Wireframe ?

[teppo]

Changelog for Wireframe 0.14.0:

### Added
- New ComponentView class, as well as the ability for component views to access Component class public methods as properties, in the same way view files and layouts can access Controller class public methods.

### Changed
- Hook related code moved from Wireframe module to separate Hooks class.
- Accessing public class methods as properties in view files were moved into new trait MethodPropsTrait. This is used internally by Controller and Component classes.
- Some minor improvements related to dependency injection within Wireframe objects (and ProcessWire objects instantiated by Wireframe.)

@bernhard, what you suggested here...

  On 8/28/2020 at 10:09 AM, bernhard said:

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

Expand  

... is now doable. The way it works is just like with Controllers (this functionality is provided by a new shared trait behind the scenes):

<?php
// component class
namespace Wireframe\Component;
class Test extends \Wireframe\Component {
	public function hello() {
		return 'world';
	}
}

// component view
hello <?= $this->hello ?>

 

[mlfct]

Hey @teppo,

first off thank you for creating this module - really love the approach. I recently took over a processwire project, which pretty much consisted of php/html spaghetti-code. Being an processwire greenhorn (having worked with Typo3 & WP up until now), this drove me crazy - but your module definitely helped me to bring some structure into that chaos. ^^

Anyway, long story short: 
I was wondering, if i can also use blade or twig templates for the view part of a component? It works flawlessly for all my template & partial views, but i am somehow having issues with components. Always running into something like this, although an default.blade.php view exists for that component:

Method Wireframe\Component\SocialWidget::__toString() must not throw an exception, caught InvalidArgumentException: View [SocialWidget.default] not found.

I might also just be missing something, as i only have an intermediate knowledge of php.

Thanks in advance!

[teppo]

@mlfct, what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

That being said, I don't use twig/blade myself, so if the issue still exists in the latest version, I'll have to dig in to see what's going on.

Also, thanks! I'm really glad to hear that uou've found Wireframe useful ?

[mlfct]

  Quote

what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

Expand  

I've been using 0.14.0 from the your repo master branch and mauricius' blade renderer implementation. 

[teppo]

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1. Simply put the Blade renderer appears to expect component views to be found from /site/templates/views/[component name]/[view name].blade.php, while Wireframe expects them to be at /site/templates/components/[component name]/[view name].blade.php ?

I would recommend keeping tabs on that issue if you want to use Blade. Twig implementation shouldn't have the same issue, though.

[teppo]

  On 9/13/2020 at 8:19 AM, teppo said:

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1.

Expand  

This issue is resolved in the latest version of WireframeRendererBlade. Let me know if the problem persists, though ?

[mlfct]

@teppo was already following up on the github issue. works perfectly now - thanks for pinpointing the issue and chiming in with mauricius!

[teppo]

Just a quick heads-up that Wireframe 0.17.0 went live a few hours ago. Versions 0.15.0 .. 0.17.0 mostly included behind-the-scenes improvements and refactoring for existing features, so didn't think these were particularly interesting. Full changelog can be found from CHANGELOG, as usual.

Probably the one and only feature that might come in handy during development is the shortcut method for defining view template and view at the same time (to use a view from a specific template instead of current one), added in 0.16.0:

<?php
// find blog posts and render them using the "list_item" view of the "article" template:
?>
<ul>
	<?php foreach ($pages->find('template=blog-post') as $post): ?>
		<?= $post->setView('article/list_item')->render() ?>
	<?php endforeach; ?>
</ul>

On a loosely related note I've removed the "WIP" label from the topic of this thread, and am considering submitting the module to the modules directory. I think it's long overdue, really ?

[bernhard]

Hi @teppo

any ideas why I'm getting this error on a fresh install?

Notice: Trying to get property 'paths' of non-object in C:\laragon\www\micropage\site\modules\Wireframe\lib\Config.php on line 163

Warning: Creating default object from empty value in C:\laragon\www\micropage\site\modules\Wireframe\lib\Config.php on line 173

Also the directories look weird. The regular directories have not been created, but they are also not listed on the settings page:

[teppo]

Hey @bernhard! Thanks for reporting this.

The latter problem is connected to the first one. Config screen asks the main module for the paths object, but due to a recent change this wasn't available. This is fixed now in the latest version of the module (0.17.1).

[teppo]

New release — 0.18. This version adds Tracy panel for Wireframe:

Obviously the panel will only show up if both Wireframe and Tracy are installed. Currently it displays some content I thought could be useful while developing, but I'm open for suggestions. Tracy doesn't really enforce any rules here, so in the future the panel could also provide interactive developer tools or something along those lines... just not sure yet what would be useful ?

Thanks to @adrian for adding support for custom panels!

[adrian]

Hi @teppo - getting this on PHP 8

Fatal error: ProcessWire\Wireframe::__set(): Return type must be void when declared in /site/modules/Wireframe/Wireframe.module.php on line 842

[teppo]

Thanks for reporting this, @adrian! The issue is clear (return types for magic methods are now enforced by PHP) and the fix is simple, but I'll have to set up a test environment to make sure it really fixes the error... and doesn't introduce any new issues ?

I'll get back to this ASAP.

Edit: the dev branch at https://github.com/wireframe-framework/Wireframe/tree/dev now contains a fix for this, if you'd like to give it a try. I'll have to test this properly before merging to master.

Edited November 28, 2020 by teppo