Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 08/25/2019 in Posts

  1. 3 points
    Please do – the core would definitely benefit from this πŸ™‚
  2. 2 points
    Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!
  3. 1 point
    To complement what @teppo said, here's a post by Adam Wathan, one of the creators of Tailwind CSS, that made me want to test the framework. I was skeptical at first but after I built my first project using it, I was hooked. https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
  4. 1 point
    Additional side note: It seems my post confused a few of us. Therefore a few more details about my workflow. Clarification The above mentioned workflow does not involve ProcessWire. This workflow applies only to the part of creating HTML, CSS and JS for a project in its static version. You can call it a prototype, a template library, a loose collection of web-related documents, or however. This step is done way before I fire up ProcessWire (or give the files to another developer in case of Typo3, the CMS we don't name here or whatever). Each time I start a new client project for a website I already have in some kind a full-featured, defined and approved design - either made in Adobe PS, IS, XD, Sketch, Figma or any tool you can imagine - most of the time it's not my part to be honest. I can then work out each and every detail, plan out the things that were needed, look for repetitive elements and their modifications and states. The result of that (my work) needs to get an approval by the designer and the client - afterwards I create a new ProcessWire instance and migrate everything in template files and smaller bits I will need later on. With this overall approach I have had enough time to know how to structure the data and content in ProcessWire which makes things in it super easy and super fast most of the time. Hope this helps.
  5. 1 point
    Tailwind is utility-first framework. The key difference between something like Uikit and Tailwind is that latter has none of the typical CSS framework components built-in. For an example, here's an example from the docs for creating a "button component": <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"> Button </button> Colors and sizes (such as the "2" in "py-2" etc.) are configurable, so you can have as many or as few of them as you want, and the names can pretty much be whatever you want them to be (py-thon). Either way you're always building your UI using really simple (the word "atomic" comes to mind) rules. While Uikit has some similar utility classes (and so does Bootstrap), Tailwind has a massive number of them, even without counting the pseudo states (bg-blue hover:bg-blue-dark), responsive classes (p-6 md:p-8 lg:p-10), etc. You can still create your own "custom" components, so that when you add some class – such as "btn" – to an element, you actually get the same thing you would with the rules in the example above. Typically this is done by defining the class in SCSS: .btn { @apply font-bold py-2 px-4 rounded bg-blue-500 text-white; } .btn:hover { @apply bg-blue-700; } Technically that this is something you should only do if you really have to repeat the same string of classes multiple times, though πŸ™‚ Personally one thing I've always struggled with "traditional" CSS frameworks are the components they come with. While they often look quite nice, I've almost never had the chance to actually use them as-is (either there's a predefined PSD layout or something like that, or the client demands changes, or the component is just plain bad) and thus I've basically ended up designing my own component library on top of the one provided by the framework. In most of my projects I've only used a framework like Foundation for the grid implementation. That's where Tailwind comes in: you can build exactly the components you need, BUT you still get certain benefits of a framework, such as globally defined fonts, colours, spacings, etc. I've struggled with this a bit, and I have to agree that to me personally the utility class approach often looks really ugly, and the shortcut class names etc. are hard to decipher. I'm not yet at the point where I can just glance over an element and instantly see what it is or how it's styled. That being said, I don't really think that this is a major issue for most projects: the size of your HTML is unlikely to become a real bottleneck. ... and if it does, you can always use the extracting components approach mentioned above. Use Tailwind for prototyping, and then convert the combinations you use often to custom components (or custom utility classes) πŸ™‚
  6. 1 point
    OMG, my dream come true! 😁😁😁I will use for sure multi form pages! And I will be able remove pages used for a simple yes/no! Thanks so so so much!
  7. 1 point
  8. 1 point
    Paginated forms: Looking > Forward > To > This > Alot. Thank-you!
Γ—
Γ—
  • Create New...