Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by mindplay.dk

  1. spent an evening trying to learn #Composer - getting nowhere, understanding nothing. this thing needs a tutorial "for dummies", like me! :-/

  2. If this post reaches MA, will I receive a fine? Fuck Fuckityfuck Fuckityfuckityfuck! Free speech, brah.

  3. our health insurance does not cover a $200 foot support, for which we have a prescription. we pay $1200 a month. #healthcare #hoax #furious

  4. http://t.co/XEAOPN2U one reason why I swear by Allman-braces, and why @yiiframework code is cleaner than proposed PSR-2

  5. Lindelof totally ruined Prometheus - what a letdown. This guy should not be writing. :-(

  6. made it around Lake Treman in one piece and decently fast! #proud #tired #nearing40 :-)

  7. All of our clients loved it - it was one of the most celebrated features of our CMS. And I like getting my hands dirty! I've already been trawling through the innards of PW to see what makes it tick. I'm never quite happy having to accept abstractions that "just work" - every abstraction has it's limitations, and it helps me use a tool more efficiently if I can understand what's going on underneath the skin. And I'm happy to say, PW is a lot more transparent and easier to understand than most CMS I have examined!
  8. Very true, and these are the main reasons I became interested in PW to begin with. This is not exclusively an issue of rendering though - inheritance rules, and how the content manager (person) experiences this, that's what I'm trying to figure out. Here's a quick illustration of a block-based UI we had in a CMS I used to work on: https://docs.google....6mfI/edit?pli=1 One idea that just occurred to me is this: instead of just "fall down" (enable inheritance) on a block-instance, it could have two options: "fall down before" and "fall down after", so that parent pages can control whether inherited blocks appear before or after child-pages. Then the drag-and-drop sorting might work - you wouldn't need the priority number anymore... (PS: smilies do not work well on this forum - why do I get a suprised-looking smiley every time I insert a happy-face?)
  9. a class I wrote that can serialize/unserialize an entire PHP object-graph to a JSON string representation https://t.co/JInvuy7K

  10. I know you can sort pages in a single list - but that doesn't account for sorting when blocks can be inherited from parent nodes. You need a priority/weight, so that parent nodes can add blocks both before or after page-specific blocks. At least that's how block-systems traditionally work. Keep in mind, the priority is not specific to the block "types" (templates) - you could have a "static HTML" block for instance, used in different places, with different priority...
  11. Prometheus opens in 2 days. psyched!

  12. That sounds reasonable, definitely gives me something to go on, thanks! Perhaps better would be an extension of the page field-type, adding UI-level support for sorting and inheritance? Do you think that would be meaningful, or would I be swimming against the current?
  13. Just starting to look into PW, and really liking the concept so far. I think this question may have been asked, possibly here or here - but maybe not quite the same issue. I'm looking for a way to do a "portal"-style block-system, but with inheritance. Drupal doesn't really do this (or doesn't do it well) and I'm not sure it's quite what was asked for in those other two threads, so let me try to explain. Basically, I want to allow the content administrator to place arbitrary blocks in, say, a left and right sidebar. These blocks could be anything from just a title and some static HTML, or something more complex like a Google Map or some kind of calendar or "social" widget. Blocks should "fall down" through the hierarchy (perhaps optionally) - meaning if you put a block on a parent page, child pages should inherit it automatically. The blocks should be prioritized, perhaps using a simple "weight" or "priority" number for sorting. The point is not to compose pages or build articles (such as is done in Concrete5, for example) - but something more along the lines of what StackBox CMS does, where content-locations ("positions" or "slots" or whatchawannacallit) can be shared... somehow ;-) Make sense? Is there a sensible (performant) way to approach this in PW? I'm thinking of one possible approach, which is to have these "blocks" actually be hidden "pages" with various templates, one for each kind of "block" or "widget" - located under a pair of hidden "left column" and "right column" pages in the hierarchy, which would determine the "block" order/priority by simply sorting them under these two parents. The page-templates can simply use the API to fetch the list of "block pages" for reach column, and render each of them in order. What I can't figure out is how you would achieve the "inheritance" effect - blocks "falling down" to subpages, based on the page-hierarchy itself. One idea that comes to mind, is to use tags - so for instance, if I tag a page with "advertising", any "block page" tagged with "advertising" would be fetched and displayed. To find inherited tags, however, I would have to actually walk up the page hierarchy and look for additional tags for which to query blocks. I suppose that would result in more overhead the deeper the page is nested - so maybe that's not a good idea? Can you think of better way (or more in tune with the "PW mindset") to approach this? Thank you for making this CMS available! I'm pretty excited about this, and I have a feeling this might be the (sane) Drupal-alternative I've been waiting for! ;-)
  14. UI has come full circle: from rounded, shiny, textured, graded, glowing, glassy - to flat, simple, square, monochrome http://t.co/Kb4lKpiC

  • Create New...