timothyhinrichs / clicl Goto Github PK

When getting a list of items and displaying them with a table, the current 
implementation is such that one table is built for every attribute of the item.
Let's say I pick from the db 2 items: 
    Item0(id=0,title=item0)
    Item1(id=1,title=item1)
If I create a table based on the item schema, the result will be:
- a table for the id field
    ID = [0,1]
- a table for the title field
    TABLE = [item0, item1}

The tables should be merged in a single table instead.

Weblog updates are assumed to be datalog (i.e. in rule form and safe).  Need to 
have the language enforce this.

When a user fills out a Weblog form but the servlet reject it, Weblog does not 
repopulate the form and include error messages.  Instead, it provides a 
printout of the errors and why.

Plato doesn't yet accept error messages for constraints.

This is partly by design because when Plato combines constraints it would then
need to generate a new error message for the combination.

Implementationally, it is hard to do that because we're using Snark to compute 
the resolution closure.

Suggestion: attach error messages only to the original constraints.  For the 
case when the resolution closure is just the original theory, everything works 
out (which is always true for non-interacting constraints---a common case).  Or 
even more simply, just keep the error messages around for complete theories.

Syntactically, we can change the input language for constraints so that they 
are ...
(formula1 "explanation1"  formula2 "explanation2" ....)

Internally, perhaps we can just maintain a simple alist (formulai . 
"explanationi").  Then when we convert each formula to clausal form, we just 
replicate explanationi for each clause generated from formulai.  Finally, when 
doing the compilation we simply check if for an error message using sent-equal. 

It is natural to have constraints that require values for certain fields.  Such 
constraints are only falsified when that field is disabled (though see HTTP 
spec for when a value is not submitted to the server).  Checking such 
constraints on the client requires analyzing DOM properties.  

Another example of such a constraint is VISIBLE. 

Add to Plato a mechanism for implementing constraints that check/change DOM 
properties.  

A possible error handling flow:

Regular flow:
servletA ----(guardX)---->servletB

if the guardX fails, we could deviate the flow like that:

servletA---->(guadX:fail)--->error-handler(next_page = 
servletB)------>[servletA with some error message || some other servlet - e.g. 
login servlet]------->servletB(by getting next_page)

guardX : 
    if check1 fails
        invoke error-handling-servlet (to page)

error-handling-servlet(to_page)
    set-cookie(next-page = to_page)
    invoke some other servlet
        or
    just go back to servletA with some msg

Weblog does not currently move constraints from DB schemas onto Form schemas.

More precisely, once we ensure that each servlet handles 1 form, we can move 
constraints back and forth between the DB/Session/Cookie/Other signatures to 
the Form signatures (i.e. by analyzing the updates to see how the input 
schemas, output schemas, and storage schemas interact.

The benefit is modularity: declaring constraints in one place ensures the 
constraints are enforced everywhere. 

Need to employ Plato to do real-time constraint checking on forms.

Right now, I believe there is a compilation step to run Plato and create the 
requisite JS.  I don't remember whether or not it actually works.

Problem:
Displaying a list of items with dynamic content.
Webid example: list of available auctions with an edit link for each one

Tim's idea :

"Compare 2 forms: (i) the regular form and (ii) one with a
drop-down list of all possible auctions you're allowed to edit.  The
two offer the same functionality: clicking on an auction allows you to
edit the auction, but they are rendered (quite) differently.  That is,
I wondered if we could push this problem into the renderer of the
form.  So if each form has a specific type of renderer (where there's
really little harm in allowing a developer to write their own
renderers), then we still get the functionality/security we want
without requiring a massive change to Weblog."

Plato currently assumes that all the JS/HTML it produces is the only JS/HTML on 
the page.  So that we can use Plato to construct multiple forms all on the same 
page, Plato must utilize namespaces to modularize the code it outputs.