mindplay.dk

That's the point! Moreover, you don't give a hammer to a 2-year old and let him loose on your furniture Or to use another analogy, we're currently giving the client a full workshop, when maybe all he needs is a couple of tools. "With great power comes great responsibility", and so on - your clients probably aren't web designers or web developers, if they were, they wouldn't need you. And I would add to this growing list of arguments: WYSIWYG is probably the most common component in any and all CMS - it's the one tool that the client (most commonly) uses to edit the majority of the content on their sites. What I mean is, the majority of user-managed content in any CMS, is probably input via WYSIWYG. Yet, it's one of the most neglected features of any CMS - for the most part, we just pick an existing WYSIWYG and drop it in, with some configuration, or some minimal CMS-specific extensions for uploading/images, etc. I think we can do better than this? @ryan I skimmed through your article, and basically, it looks like you've had many of the same thoughts I'm having. WYSIWYG has been around for so long, it's hard to challenge it. WYSIWYM failed. Markdown (et al) found other niche uses, but couldn't replace WYSIWYG either. I have attempted at least 3 different things in the past, none of which were adequate. I can't seem to let the idea go though - there must be a better way. By the way, the idea I'm hatching is actually a variety of WYSIWYG - I'm not saying a content editor shouldn't show you what you get, I definitely think it needs to do that, for clients to understand and connect with what they're creating. I'm saying a content editor can be richer, more structured, and more user-friendly - it should be able to drive meaningful decisions, produce beautiful, consistent output, and, well, all the shit you don't get from an HTML WYSIWYG

I came across this article, which highlights a number of issues with Joomla - it still seems to me that the root cause of most of these issues is WYSIWYG, and that basically any CMS suffers from many of the same issues. I quickly jotted down some notes here which captures in more detail what I've been trying to say in this thread...

My issue isn't primarily with the use of statics - there's a right time for statics, but there are far more cases where they're wrong. My main issue is separation of concerns - when a class has too many responsibilities, inheritance doesn't "work", and object lifecycles become too complex. Classes with responsibilities that switch or change over time is one indicator. Multiple stages of initialization, e.g. __construct(), init(), ready() is another indicator. To use a simple example, let's say the class X_Y_Z has three responsibilities - assuming it's not doing three things at once, it's usually better to break this into 3 classes X, Y and Z each with a single responsibility, and then introduce a composite class A with properties $x, $y and $z... the problem with class X_Y_Z is that, if you extend that class, your extension needs to deal with 3 areas of responsibility, even if your extension actually only affects one or two of those responsibilities. The higher number of classes actually reduces complexity by allowing more granular composition. If X, Y or Z have different lifecycles, as is likely if they have different responsibilities, their individual lifecycles can consist more naturally of __construct() and __destruct() as is the idea with OOP - partial initialization (initialization in stages) happens in X_Y_Z because it has different responsibilities at different times, which I find to be an indication that it's time to refactor. Of course, once you have enough dependencies on something, refactoring becomes increasingly costly - and in the case of a modular CMS like PW, this impacts a lot more people, and I'm not advocating a big change right now. I certainly don't have the time to propose and entirely new API right now, too many other things going on. Just trying to provide some architectural feedback, to improve things for developers in the future. It's not even unthinkable, like you suggest, that an improved API could remain backwards compatible. I wish I had more time to contribute to this, but we're planning a move this summer, so I've really got too much on my mind right now. Sorry I can't provide more concrete suggestions.

I don't want to get into a long drawn-out discussion, but suffice to say, some of your answers simply explain how things currently work, which I already know - if you'd like, you can read my answers again and assume that I already know what you told me, maybe you'll extract something new from my comments. I'll just briefly comment on two things. But the consumer does have to think about this variable - it's crucial to know when you ask for wire('modules')->xyz whether that returns a shared instance or a new instance. My point is that these are two entirely different life-cycles, and that fact is not expressed by the API in any way. The module container doubles as a factory-class - it provides services as well as components, with no obvious distinction in the API. That doesn't seem right to me. Actually, you're spot on - I was excited about Laravel at first, but then I looked under the covers... I'm already suffering with the limited extensibility of a framework that uses statics (Yii) and I find it crippling when I want to override or extend core functionality. Code that consumes a static interface is hog-tied to the class - meaning you can never extend, override or replace that class, because the class-name itself is referenced in all the consumer-code. It makes my brain hurt. It really does. Frameworks (and preferably all code) need to be completely open to extension - statics get in the way of that, in a huge way. Yii is bad enough - Laravel would probably make me want to kill people. Simply put, things like Database::getConnection() is fine until you want to override the getConnection() method and you realize that all the consumer code is filled with static references to the Database class. Where does your extended class fit it? It doesn't. So you're left to either hack the Database class, fork the framework, override a class-path in the autoloader, or some other horrible hack. Statics in general: no thank you. The only time you should use the word "static" is internally in a class that, say, caches something. A consumer API should never, ever use static interfaces...

Whenever I see the static keyword, I cringe, and I automatically start scrutinizing my code to try to understand why I'm using it - the more I do that, the more I find that investigating your own motives for using statics usually (if not always) reveals a design flaw. It sounds to me like the Module concept really has several different things sort of huddled into one class. The fact that the class itself has a life-cycle that begins before it's even constructed, is one indicator - the class itself has an area of responsibility that begins before it even exists. Another indicator is the configurable options that affect the object's life-cycle - a static/singleton module tends to work more like an application-wide, shared service component of some kind, while other modules such as Fields are accessed through the same container (wire('modules')->xyz) where now the container suddenly works more like a factory than a service-broker. All of these differences could be modeled more explicitly using interfaces and polymorphism, as opposed to static methods and configurable options that affect the behavior of framework components and life-cycles of module objects. I would suggest rethinking this architecture for a future major release. For example, a module, conceptually, is a singleton - it consists of one set of files implementing classes, both of which are by definition singletons, hence, every module is going to have one singleton object providing information/metadata about the module itself. It would be natural to refer to the base-class for that object as the "Module". By making that it's only responsibility, you can eliminate the need for statics, and the Module class itself becomes much simpler and more lightweight. Modules that implement a module-wide configuration screen could provide the configuration model/form via an interface, e.g. a ConfigurableModule interface with a getModuleConfiguration() method, returning a dedicated configuration object of a type that implements an abstract ModuleConfiguration base-class. This eliminates the need for those static methods, and enables better composition, e.g. the freedom to extend different configuration base-classes for more specific purposes, etc. - it also isolates the responsibility of configuration and the configuration-form, enabling the code to load independently of the module itself. Similarly, modules that implement InputFields, which are not singletons, could implement another interface, e.g. FactoryModule, with a method createInstance() that returns an InputField or something else with a non-singleton lifecycle. This provides more separation and eliminates the need to load the instance-types before they're needed - and those instance-types can now deal exclusively with their area of responsibility. This also clearly separates service singletons from component instances, and gives those types a distinct lifecycle - by introducing the same separation in the framework API, this becomes more obvious to the consumer as well, e.g. wire('modules')->FancyInput refers to the FancyInput Module singleton, whereas e.g. wire('factory')->create('FancyInput') clearly is expected to create a new instance of a component provided by the module. And so on along those lines. I hope you're not opposed to making architectural changes in major releases in the future? Many architectures of this type (Drupal and WordPress to name two) are set in stone, and even major releases don't tend to break backwards compatibility, but nothing ever really improves. Drupal was actually nice when it came out, it had some good ideas at the core - but time ran away from it, because the selling point "lots of modules" is hard to argue with, and breaking backwards compatibility (in a major way) can feel like starting over. In my opinion, if you make substantial improvements to an architecture, it's worth breaking backwards compatibility. We should not reject new ideas because they're not compatible with our current world view or legacy components - if we do, we can't make never make any real progress. Anyways, </rant>

This is precisely what I ended up doing - but according to what you just said, that could cause problems, since I'm now forcing the module to load at configuration-time. (?)

Like the topic says, why? It's causing me all sorts of pain - because the module configuration callback has to be declared as static, getting to properties inside the module is difficult, so I ended up switching a lot of instance-variables to static, so that I could get to them, which causes even more mess and confusion. It appears that, by the time the static method is called, the module has already been instantiated anyway - so what reason is there for this to be static? Really frustrating...

I gave it a shot, and it doesn't work any better - for example, $collapse and $columnWidth and something called $clone_field is reported as having changed every time. I also have the following concern: If I set $trackChanges=true when the Field or Template is loaded, and some other module attempts to track changes, that module may be tracking more changes than it intended - and conversely, it may be setting $trackChanges=false sooner than expected by my module. It doesn't sound like that's going to work? Furthermore, I've seen in a bunch of places things like trackChange('unset:'.$name) which suggests that some of the keys in $changes may not actually be property-names? - so I would have to somehow whitelist the keys I get back from $changes to make sure I only pick up actual properties. It's starting to sound like more work than what I'm currently doing, and sounds like this approach may be more error-prone as well? Unless you disagree with those assertions, I think I will stick with my current approach - it's not as elegant, but it seems safer and less likely to disrupt anything else...

I will do some experiments with trackChanges() when I have time, and report the results here...