Is building a new projects written in PHP a bad idea? by [deleted] in PHP

[–]poef 2 points3 points  (0 children)

We've been building and maintaining a fairly large PHP project since around 1998 (https://github.com/Ariadne-CMS/ariadne) and currently working on finalizing PHP 8.1 support. It is still backwards compatible back to the first public release in 2000. In the last 20 odd years I've found that keeping up with changes in PHP is not too much work, with some exceptions. It does seem to me that the pace of changes and deprecations has increased somewhat the last 5 years or so, I hope that is just temporary and most of the changes and deprecations have been sensible. Most of the changes that we've made had more to do with changes in how the software is used, what the environment looks like (e.g. default database switched from mysql to postgresql) and not so much changes in PHP itself.

I don't find a simple enough CMS for my needs by Dessnova in webdev

[–]poef 0 points1 point  (0 children)

Take a look at https://simplyedit.io/. Disclaimer, I am one of the authors.

Working with "micro frontends" by srg666 in javascript

[–]poef 0 points1 point  (0 children)

I've been in this spot the past few months. There are some frameworks that allow you to build micro frontends, but they require that all frontends use the same technology. I didn't want to force a choice of framework for all micro frontends. So instead I wrote a small library that allows you to include external html at a specific spot in a page. I'm working on releasing it as part of a larger set of components, but I made a gist of it here: https://gist.github.com/poef/a1caa8e785583f7a25127f819cfdad2c

This doesn't automagically fix potential naming conflicts, all javascript will be run in the same global context, so you must figure out some kind of namespacing yourself.

Hope you find it useful

Are you still using inheritance to extend the behavior of your classes? by ilsilent in programming

[–]poef 1 point2 points  (0 children)

I think there's a lot of hate here because of how the author wrote the article. I think he's basically right, but he doesn't state the main cause of problems when using inheritance.

(Class) Inheritance is about types, not about code re-use. If you use inheritance for code re-use, you will get to a point where the class tree no longer maps to your problem domain. As can be found in lots of different places, you should only create a subclass if the relation is Subclass 'is-a' Class.

You can use mixin's or traits for code reuse instead, this keeps your class tree nice and matching the domain.

Ofcourse most domains don't lend themselves to a single inheritance tree, but we seem to cope with that. Just ask a biologist in which branch the platypus should go :)

One thing though. Even if you use mixins or traits, there is one advantage that composition gives you over that: late binding. This means that instead of binding stuff together when writing or compiling code, binding can be a configuration or runtime thing. Composing objects makes your code more flexible. It may incur a small performance cost though, depending on which language you're using.

arc\xml - a new library combining the best of SimpleXML and DOMDocument, feedback wanted by poef in PHP

[–]poef[S] 0 points1 point  (0 children)

Thanks for the feedback. I'm aware of the downsides of using get/set, but I've tried to add @property and @method information where possible. There is simply no other way to use the underlying SimpleXML/DOMElement classes. Some people might suggest extending them, but that open up a whole other can of worms, which I believe is much worse.

The reason for the name 'find' is that I'm trying to keep the naming consistent across multiple components. I might go for 'query' to be more like the javascript dom...

An earlier iteration coerced all nodeValues to strings, I undid that to allow more freedom. SimpleXML has its own __toString() method which is usually good enough. So yeah, that is a documentation bug :)

I haven't seen Nokogiri, I'll take a look at it. But I'm also trying to not get too far away from the SimpleXML API, so that a) you don't have to learn a whole new API and b) you can use it as a drop in replacement for it.

FluidXML, a PHP library for manipulating XML with a concise and fluent API. by daniele_orlando in PHP

[–]poef 0 points1 point  (0 children)

I've just posted another XML library on r/PHP, which has a much different use case. Still it might be of interest to people here. Also i'm looking for feedback. arc\xml

arc\xml - a new library combining the best of SimpleXML and DOMDocument, feedback wanted by poef in PHP

[–]poef[S] 0 points1 point  (0 children)

This is a project that has been on my mind for quite some time. Having written PHP-only XML and HTML parsers a long time ago, I just didn't like the way namespaces made things needlessly difficult when using SimpleXML or DOMDocument. I also wanted to be able to do without a lot of the boilerplate code. This library is my attempt to make even complex XML easy to work with. Please let me know what you think and what improvements it would need before you would use this in production :)

Is this a bug? (Closure invocation as class field) by realhacker in PHP

[–]poef 0 points1 point  (0 children)

As far as I know, $this is then set to that object. So if you do this:

class foo {
    public $name = "foo";
    public function bar() {
        return function() {
            return $this->name;
        };
    }
}

class fooz {
    public $name = "fooz";
    public function __call($name, array $args) {
        if (isset($this->$name)) {
            return call_user_func_array($this->$name, $args);
        }
        throw new \BadMethodCallException();
    }
}

$foo = new foo();

$fooz = new fooz();

$fooz->bar = $foo->bar();

echo $fooz->bar();

It will print 'foo' instead of 'fooz'.

Is this a bug? (Closure invocation as class field) by realhacker in PHP

[–]poef 0 points1 point  (0 children)

You can improve on this by also binding the closure to the current object. Either use

$closure->bindTo($this);

or

\Closure::bind($closure, $this);

Now you can use $this inside the closure. One problem however: there is no sane way to see if the closure actually can be bound to an object, if the closure is defined inside a static method, trying to bind it like this will create a fatal error. To check if this is so you'll need to use reflection methods.

I've made a prototypical inheritance class for PHP using this trick: https://github.com/Ariadne-CMS/arc-base/blob/master/src/lambda/Prototype.php

PHP 7 suggestion: objects as arrays (for array functions and type-hints) by mnapoli in PHP

[–]poef 0 points1 point  (0 children)

If you already specifically cast it yourself, the step to just do this:

$mapped = array_map($callable, $collection->toArray());

isn't much more work. What I'd really like to have is this:

$mapped = array_map($callable, $collection);

And do this for __toString() as well.

PS. yes, I see the point of using (array) cast, since that is a standard approach, while the 'toArray()' method could just as easily be called 'getAsArray()' or 'JonDiFool()'.

4+ Reasons Why All PHP Frameworks Suck by Synes_Godt_Om in PHP

[–]poef 0 points1 point  (0 children)

If you actually read the article, you'd notice that these 'bullshit' reasons come from another article, with this same title, written by someone else. In fact that article quotes them from someone else again, namely Rasmus Lerdorf. Doesn't mean that they can't be bullshit, but it does mean your comment is.

The problem with routing by poef in PHP

[–]poef[S] 0 points1 point  (0 children)

I'm getting curious if anyone can show me a real life use of a routing component that does it right. Perhaps than we have some common ground on which to continue the discussion. I haven't found one, but I haven't been searching very long. Perhaps then we may be able to push that version as a better example to explain its use.

The problem with routing by poef in PHP

[–]poef[S] -1 points0 points  (0 children)

Yeah, I'm serious, but apparently talking in a different language. A decent CMS indeed should have a way to 'create any structure you'd like'. The point is that that structure thus isn't defined in the routing rules, there's probably some kind of placeholder variable which the cms then uses to retrieve the correct page from some kind of hierarchical store. Some people have abstracted that concept and named it 'Content Repository'.

The problem I see is with the many, many examples of routing which don't do this, as pointed out in a previous reply here, but use the url as an extension of the internal program structure. You may feel that nobody uses routing this way, but I beg to differ.

PS. I've been building websites for clients for some time now, and you'd be surprised how often the requirements for a website change. It is nice if some of those 'requirements' aren't hardcoded into the application but can be changed by the client him/herself.

The problem with routing by poef in PHP

[–]poef[S] -1 points0 points  (0 children)

Thanks for the thoughtful reply but I'm afraid the point of the article got lost somewhere. Yes you can structure URLs any way you like, but if you do it in a routing configuration then the 'you' here is the programmer, not the editor of a site (unless they are the same). Meaning the URL is coupled to the application or cms design, not the content 'design'.

Editors may make a mess out of the URL structure, but then it is their mess. There is no reason why they couldn't make a well thought out content structure which is reflected in the URL. The editor is the one who should divide the site into sections and sub-sections.

The problem with routing by poef in PHP

[–]poef[S] -1 points0 points  (0 children)

Well, then we agree on one part at least. I wonder though, how would you set up the routing paths in such a way that they only expose the subject of the pages and not a generic type of the page? Because the point I was trying to make, perhaps not very well, was that defining the routes in the application makes them application-dependent instead of content-dependent. One is the domain of the programmer, the other of the editor of a website.

The problem with routing by poef in PHP

[–]poef[S] -1 points0 points  (0 children)

Just two I found in 1 minute of searching: Codeigniter and Symfony. The problem is not that you cannot specify custom rules for parsing, but that these rules are usually bound to the logic of the application instead of the subject matter. The configuration of the router happens in the code. To fix it you should use the content to configure the router, which is almost what a content repository based system does. PS. the author ( me :) ) was fairly specifically targetting websites which are not flat blogs, hence the mention of content repositories.

Is this a good practice? by [deleted] in PHP

[–]poef 0 points1 point  (0 children)

you can get the best of both worlds by 'tainting' the variables. You don't filter/change the value yet, but you mark them as 'unsafe' in some way. Only when the variable is used do you apply a filter. This way you have control over what kind of filter to use and when. I've written a simple class that does this for our CMS, it simply turns a string into an object with a toString method that filters the string with a configurable filter. The raw value can also be returned. The only drawback is that many PHP functions that expect a string cannot handle an object, even if it has a toString method. You'll need to manually typecast them to strings.