Skip to content

Commit

Permalink
🎨 Removing some deprecated TODOs
Browse files Browse the repository at this point in the history
  • Loading branch information
wesen committed Nov 22, 2024
1 parent c2b4d74 commit febd489
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 76 deletions.
69 changes: 0 additions & 69 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,72 +12,3 @@ as well as exposing a set of helpers for manipulating object and tabular data.
The long term goal of parka is to create not just API services (HTTP with REST, grpc, websockets, etc...),
but also provide graphical web user interfaces to interact with them (for example
by exposing the different flags and arguments as HTML forms).


## Steps

- [x] Serve templated file (test data)
- [x] Serve tailwind CSS
- [-] Integrate glazed.Command and expose as web form / API
- [ ] Integrate with htmx for dynamic webforms and dynamic apps]

### 2023-02-25 - Working on exposing glazed commands

Now that we have a proper generic framework for commands in glazed,
we can start wrapping and exposing individual commands as APIs.

We don't want to expose all arguments to a web api however, so the question is how to
restrict parameters and arguments:

- add a new layer that specifies which arguments are exposed, how they get filtered
- annotate the original command with a `web` tag, which specifies how an argument should be handled?
- add additional section to command definition that can be loaded by parka (basically, the first option, but somehow
maybe added as an extension layer to glazed commands themselves, instead of being directly parka specific)

In fact, we may want to add parka specific attributes to wrap the command,
so an additional layer makes sense. For example, a template argument might be used generically
to specify that different templates could be used. I don't know if this all makes sense declaratively,
so I will first focus on a code only API.

What I want to achieve today:

- [x] Reload HTML/JS from disk, not embed, to avoid having to recompile every 2 seconds
- it seems like that's already how it works? odd
- this might mean I have to add back the option to serve from embed
- [ ] Wrap a simple command as both REST+JSON and web form + htmx
- does this mean we want to create a webform and go over every parameter?
- this could be a template provided by parka already (just pass it a list of parameter definitions and it creates a form)
- [ ] Wrap a geppetto command to build the rewrite prompting
- [ ] Build and package the web application for easy deployment on DO, using parka as a library

#### Exposing commands as APIs

There is already a whole function for exposing commands as APIs, so I'm going to build upon that.
What I want to do is be able to specify a HTML template to render out HTML, when called in a certain
form. In fact, because of htmx, it might make sense to call a single wrapped command
with different endpoints / additional parameters.

#### How much CSS / MD / HTML to bundle with the parka package itself

To make it easy to just bang out UIs, a fair amount of CSS and base HTML should already
be bundled with the package itself. It should be possible to just import parka, register
a command, and get going.

But, we should make all these things overridable too. But let's start with a single simple override.

### 2023-01-30 - Brainstorm parka structure

So now I want to make this a bit more useful.
I want to be able to serve markdown from multiple sources, so there should be
a mechanism to register sources of markdown to prefixes, the same way the fin router can do the
`r.Use()` stuff.

`r.Use()` takes a middleware handler function, so probably that's how things should be done,
along with helper methods (?).

The handlerFunc takes a `gin.Context`.

But also, it could all be much simpler, and we can just have the application register
a set of lookup functions that return markdown content for a certain prefix.

The server can then go through and take the first matching one.
11 changes: 4 additions & 7 deletions pkg/server/server.go
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,10 @@ import (
"context"
"embed"
"fmt"
"io/fs"
"net/http"
"time"

"github.com/go-go-golems/parka/pkg/render"
utils_fs "github.com/go-go-golems/parka/pkg/utils/fs"
"github.com/labstack/echo/v4"
Expand All @@ -12,9 +16,6 @@ import (
"github.com/rs/zerolog/log"
"github.com/ziflex/lecho/v3"
"golang.org/x/sync/errgroup"
"io/fs"
"net/http"
"time"
)

//go:embed "web/src/templates/*"
Expand All @@ -24,13 +25,9 @@ var templateFS embed.FS
var distFS embed.FS

// Server is the main class that parka uses to serve static and templated content.
// It is a wrapper around gin.Engine.
//
// It is meant to be quite flexible, allowing you to add static paths and template lookups
// that can provide different fs and template backends.
//
// Router is the gin.Engine that is used to serve the content, and it is exposed so that you
// can use it as just a gin.Engine if you want to.
type Server struct {
Router *echo.Echo

Expand Down

0 comments on commit febd489

Please sign in to comment.