Features

Ever wish that your web development frameworks had a lot of flexibility, a dedicated UI and a quick learning curve? Look no further than Hoopla, the framework for small development teams that keeps everything at the right scale. We provide the starting point, dealing with the low-level object storage and retrieval basics. You add to it the parsing and output tools you like. Our base export library is small, efficient and covers everything your website will need to retrieve the objects you created during development. If this is a bit mystifying, let's look at how the HFW fits in with your project ecosystem and then break-out what the framework stores and retrieves through its database.

HFW Ecosystem

We provide the blue blocks. You can use the sample project as the starting point for everything else, or build your own middleware. Use the HFW for building the structure of your web pages so they can handle your dynamic content. This segregates your code so that your middleware and backend will have clear delineation. However, the framework is very flexible, so use it as much or as little as you like. The dynamic content of your app (if there is any), will also be in its own code base, and properly segregated. Of course, by static content, we mean that you will have something like a div tag or table row on your page, but the dynamic content will fill them out and determine how many of each there are. Static also implies that the HFW DB will not be altered when used on a production server and is read only.

HFW Pages

We start with the abstract notion of a web page. It can be based on some sort of REST call or other protocol that is parsed by a template written in PHP and/or Javascript. One template can parse multiple pages. If these form a set, then they can be assigned to a Page Context. This makes page-spanning value retrieval easier, as calling up the set brings up every page value, rather than needing to call them up individually. Multiple sets of pages can fall under different Page Contexts. Pages are then containers for objects.

HFW Objects

Objects are anything you want to put onto a page or need to generate a page that can be abstracted. They aren't the dynamic content of the page, since the framework is itself static, but they can incorporate dynamic content. They can be div tags, database queries, textboxes, buttons, frames, etc.

Objects are assigned to a page at will, and can be enabled or disabled on their assigned page and objects on a page will have a special ordering as needed. Their "location" tag is akin to a variable name for the purpose of template retrieval. Objects are completely abstract containers, though, so they are managed through a type system to help organize things.

The "magic" happens when objects are assigned values. They can have a default value or a page specific value, which in most cases will take precedence over the default value. One can also create arbitrary contexts for such values, and thus allow objects of a particular type to be re-used in multiple ways. Values also are typed, or are of a specific type, so you can not only have multiple values based on context, but also of differing types. This means that an object can be retrieved with one or more values at a time, or at different times. Furthermore, values (also called "settings") can have setting types, which allows one to handle objects in multiple ways, such as its HTML, and its Post/Get name.

New for 2024! We have added the ability to use context fallbacks. This means that if the specified context value does not exist, one can fall back to the default context value (def_ctx). This eliminates the need to create duplicate context values just so they exist when the context is called up.

GUI Help

The GUI provides for extensive help, both in the form of tips for each page on the left and more detailed help pages under the help menu. The export library also comes with notes in the source code.

GUI Help

While the GUI allows for convenient user input, what a developer really needs is a way to get output from the framework. So, the object storage is through the GUI and object value retrieval is through the stock export library. This is separate from the GUI code and goes with the project files to the production server while the GUI stays behind. The export library comes with several useful functions for pulling values out of the HFW database and build the individual pages. What you do with those values is up to your template code but this is probably the big headstart you were looking for. Details are both in the source code and in the Help system.

By having the source code, a developer can of course extend the HFW as they see fit, either on the GUI side or export library side. This is code for people who write code.

• We are now multi-project capable!

The GUI was always actually capable of being used on more than one project, but it was clunky to do so. We have found an elegant way to get around that and so there is a new "Projects" tab in the UI. We also list the current project on each UI page.

• Better handling of default values!

There are essentially two types of default values: page and context. Now you can use both as fallbacks when there isn't a more specific value. This is a setting for each object so that when a value is retrieved the preference goes to the specific value, then the default value if possible. When turned off the default values are not retrieved.

• Improved UI and bug fixes!

We have added the object type to dropdowns and columns where helpful. This was sometimes important information when looking to update values, but could be hard to figure out. Some bugs were also fixed. The mysqli_obj library was failing in PHP 8.2 do to a change in handling GLOBALS, and the export library had some dependencies on the not included HTML object library that comes with the sample project that were replaced with calls to the included export library. Two of the main export library calls were also revamped to make them easier to parse when reading the source code and to improve the output logic. These had to be modified anyway because of the addition of the default context fallback feature. Enjoy!

Images here might not be representative of the latest versions of the code or how it will render on all browsers or devices.