Ferreteria: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
(moved notes onto separate page; added another notes page)
Line 25: Line 25:
* {{l/htw|HyperAdmin}}: an early (2005) description of what eventually became Ferreteria's login system
* {{l/htw|HyperAdmin}}: an early (2005) description of what eventually became Ferreteria's login system
==Notes==
==Notes==
(2020-04-22) With regard to the idea that [https://geometrian.com/programming/tutorials/write-games-not-engines/ it's better to set out to write an app than to write a framework], some background:
* [[2020/04/23]] one issue around generalizing I/O format translation
 
* [[2020/04/22]] with regard to the idea that [https://geometrian.com/programming/tutorials/write-games-not-engines/ it's better to set out to write an app than to write a framework] and how this calls into question the idea of writing Ferreteria...
I started writing Ferreteria before I knew that web app frameworks (WAFs) were a thing. I didn't even realize I was writing a framework; I just ended up realizing that a lot of the stuff I'd written could be reused.
 
Later on, after writing most of Ferreteria, I still didn't know that WAFs were a thing; all I knew about was CMSs that could be used as frameworks -- like WordPress, Drupal, and Joomla. I looked seriously at Drupal a couple of times, but there were bits of it I really didn't like, so I decided to stick with Ferreteria.
 
When I did find out about WAF, my impression was that they were all heavy on front-end scripting, possibly dependent on extra server processes (aside from basic stuff like Apache/Nginx and MySQL/Postfix), and generally kinda bloaty. Not really interested.
 
So now I'm at the point where I can see advantages to switching to a 3rd-party WAF -- although I still don't know of any PHP frameworks which fit the bill (no JS required, but handling front-end GUI stuff like logins and menu-navigation). They may exist, but finding that information seems to be a slow process. (There are non-PHP frameworks which look like they might, but that'll require learning a new language-environment, which increases the amount of time-investment needed in order to get anywhere. That's not a deal-breaker, but it does weigh against those options.)
 
What I'm thinking is that I'll go ahead and get Ferreteria where I think it needs to be in order to be useful and maintainable, then take a closer look at the field and see what else is available.
 
It may be that what anyone else has written will never work as well for my brain as something I've written -- but given that even what I've written often leaves me going WTF, I don't feel huge emotional investment in that idea. e.g. I used MediaWiki for lots of stuff for many years, and found much to complain about, but it was still very useable as a framework.
 
<blockquote>You can sit down and write a game without first writing an engine, and in fact this is very often the better approach...</blockquote>
Substitute "web app" for "game", and this is in fact what I set out to do; the engine (framework) just kinda happened by accident, as I found myself doing certain operations over and over again... and then started seeing patterns across different operations which could be generalized into a class hierarchy...
 
<blockquote>Most hobby developers who “finish” an “engine” that was designed and built in isolation (with the goal of having an engine, not a game, upon completion) can’t ever actually use it, and neither can anybody else. Since the project didn’t have any goals, any boundaries, or any tangible applications, it essentially attempted to solve every aspect of the chosen problem space and consequently failed miserably.</blockquote>
Trying to make the API too general, to cover cases that I ''might'' run into at some point but haven't actually encountered yet and may ''never'' encounter, was a mistake I made at first -- but now I'm trying to be much more rigorous about requiring not only usage-cases for every function, but also documentation of at least one example, in the comments, when it doesn't seem totally obvious how a function or class might be needed.
 
I'm kinda realizing in retrospect how much Ed at [[Carrier]] taught me about app design -- especially business app design, but this article makes me think that many of the principles apply to game app design as well.
# Have a clear idea in mind of what you want
# Spell out as much as possible the mechanics of how it will work
# Code from that spec.
 
I tend to be weak on step 2 because it's really time-consuming and means a longer gap between idea and something that does anything and gives you that necessary jolt of dopamine for wanting to keep going, but I tend to fall back on it when things get too complex to keep in my head. ...if I can even figure out how to document what I've got in my head (which has been a sticking point for this latest round of revisions).
 
(When I say "it's really time-consuming", of course i mean mainly in the short run -- in the long run it saves time, because better code that's easier to maintain.)

Revision as of 14:14, 23 April 2020

Ferreteria is a web application framework I'm writing in PHP. It originally emerged from writing VbzCart, when I realized a lot of the classes and techniques I'd created (starting with the database classes) could be used for other applications as well.

Because it does not use JavaScript (JS), it is very fast; response-times tend to be comparable to a "single-page app" framework written in JS, except that the initial load is as quick as subsequent reloads and all of the navigation links are bookmarkable.

Features

  • User management
    • log-in control: email-based account creation, password reset
    • user-group assignment, group-permissions assignment
  • State persistence via URL
    • The only cookie stored is a single "session" cookie, which usually just stores the minimum needed for session security.
      • Most app-state data is stored in the URL path, without even using the ?query part of the URL, for practical and aesthetic reasons.
  • Database wrappers
    • classes for different types of tables, records
    • classes for handling forms, controls, data fields
    • functions for specific tables can be built by descending from more general classes
    • URL-linkable tables, records

Applications

Ferreteria applications I've written or am working on:

Reference

  • HTYP: official documentation
  • HyperAdmin: an early (2005) description of what eventually became Ferreteria's login system

Notes

Retrieved from "https://wooz.dev/mw/index.php?title=Ferreteria&oldid=476"