Code

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#12208 closed (invalid)

Django + Pyjamas dream

Reported by: qwertz76 Owned by: nobody
Component: Uncategorized Version:
Severity: Keywords: django pyjamas
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I am dreaming of a real cool combination of Django and Pyjamas:

Declare DB and Django/Pyjamas relevated things on the Model layer:

  • basic pyjamas handling (like min/max for Integers) (Field def)
  • history handling including Relationship levels (0=off, 1=this_obj, 2=nextRelationLevel, 3=nextRelationLevel+1, ..., -1=alldepth) including needed methods for handling incl. diff per Field
  • change/delete requests (Field/Model level)
  • ACLs: Table/Column/Row/FieldInRow; read/write/delete/deleteRequest/change->write?/changeRequest
  • Extensible Field Parameters
  • Re-Enable validators on Field basis, can be complex objects querying the DB
  • Translation on Field basis (boolean translate)
  • Ordered Relations, as simple relation class and as abstract Inheritance class for further Fields

Declare GUI in Pyjamas:

  • own complex GUI classes and widgets
  • use of external module loading and callbacks from Django to make everything like a GUI app

Funktionality:

  • use Mapper/Proxy classes as connection between Django DB definition and Pyjamas GUI
  • have all functionality here or mapped to non-GUI DB classes describing a workflow
  • instead of editing HTML templates just offer convinient funktions to Pyjamas

Wouldn't that be great ?

I know that this somehow compromises the everywhere hold up MVC pattern - but:

at the stage of defining my database I already know the key parameters and how I want to present and format/convert/validate/match a value to the user ...

Then writing the application itself with Pyjamas defines the real presentation.

The mapping layer would in the end simply connect the defined table-colums to a generic Pyjamas view where the detailed layout could be defined or also be delegated again to a DB lookup for user defined layouts ...

That would really be kind of rapid application development - everything in Python !

Attachments (0)

Change History (2)

comment:1 Changed 4 years ago by ubernostrum

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

It sounds like what you want is a completely different framework.

comment:2 Changed 3 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.