[project-open-development] Sencha Roadmap(?) [AW: AW: Gantt Libs]

[Frank B. <fra...@pr...>]

Hi Malte,

I'm current using the intranet-sencha package as a container 
for the Sencha libraries. I'm also adding some portlets there 
because I don't have another place at the moment. But I plan 
to remove them as soon as the place of Sencha in ]po[ becomes 
more clear.

In general I believe that it's a good idea to create a package
"intranet-sencha" as a wrapper for all Sencha stuff because
of license reasons. intranet-sencha would be licensed under
"GPL V2.0 or higher", which is compatible with the Sencha GPL
V3.0 license. Normally it would make sense to include the Sencha
stuff in intranet-core, but I don't want to do this because of
license reasons. Maybe there will even be an OpenACS package 
with the Sencha libraries?

One word concerning JSON data sources: I believe the right way
to deal with this is to enable the intranet-rest package to 
create JSON format. This way we could get a _generic_ interface
to _all_ ]po[ objects and including permissions.
I could imagine to create a Sencha library in the future with a 
"model" replicating the ]po[ data-model. This should enable 
users of the Sencha Designer to create customer AJAX screens 
easily. But that's just for the future.


Concerning timing/roadmap:

- I understand we all are currently in an "exploration" phase 
  exploring the possiblities of Sencha.
  I understand the all of the code currently created might 
  undergo changes once we get a clearer picture of the role of 
  Sencha in ]po[.
  Also, I've already found numerous bugs in Sencha Ext 4 beta3.
  This is not production ready yet.

- In the medium term we'd probably have to build the JSON support
  into intranet-rest. Also, I could imagine to rewrite frequently 
  used pages like the ProjectListPage etc. to use Sencha grids etc.

- On the long term I could imagine to rewrite large parts of the 
  ]po[ GUI to use Sencha. 
  However, we'd have to look at issues with JavaScript speed and 
  concurrent write access (two or more updates on the same data by 
  different users) etc. 

So we're now in the "exploration phase". Anything goes, but we
should be careful what to include into the "Product". But add-on 
packages and callbacks are great, so that's the way to go.

I really want to thank you Malte for your initiative towards Sencha.
You really pushed the library and I believe we all are following.


Cheers!
Frank

---
Frank Bergmann
Dipl.-Ing., MBA
Founder ]project-open[
Tel: +34 933 250 914
Cell: +34 609 953 751
Fax: +34 932 890 729
mailto:fra...@pr...
http://www.project-open.com/

-----Ursprüngliche Nachricht-----
Von: Malte Sussdorff [mailto:mal...@co...] 
Gesendet: Donnerstag, 28. April 2011 14:02
An: Frank Bergmann
Betreff: Re: AW: Gantt Libs

Wir intranet-sencha jetzt das Meta Paket? Dann packe ich da meinen Code auch
mit rein. Müssen ja nicht zwei davon haben, außer Du hast Lizenzgründe.

Liebe Grüße
 Malte

Am 28.04.2011 um 13:40 schrieb Frank Bergmann:

> Hi!
> 
> 
> Checkout intranet-sencha/lib/scatter-diagram.adp
> Here is a code snippet:
> 
> 
>    window.store1 = Ext.create('Ext.data.JsonStore', {
>        fields: ['x_axis', 'y_axis', 'color', 'diameter', 'caption'],
>        data: @data_json;noquote@
>    });
> 
> 
> So I'm creating an "inline" $data_json in the .tcl page.
> This is not the "inline data" presented in the Sencha presentation, 
> but it works!
> 
> Cheers!
> Frank
> 
> -----Ursprüngliche Nachricht-----
> Von: Malte Sussdorff [mailto:mal...@co...]
> Gesendet: Donnerstag, 28. April 2011 11:28
> An: gilles dolet
> Cc: vin...@pr...; 'Klaus Hofeditz ]project-open['; 
> fra...@pr...
> Betreff: Re: Gantt Libs
> 
> Hi Gilles,
> 
> if you tell me what you need the data inline for, I might be able to 
> help. I would not recommend to pass the Ticket Data inline as this 
> makes your JS page really hard to read.
> 
> The benefit of using a JSON file which is PULLed by Sencha is that you 
> can have a progress indicator "Loading Tasks" show up on the page, 
> making your tasks page more responsive to the user. If you use inline 
> data then you end up pushing a page with all the data to the user before
he can view it.
> 
> Or maybe I completely misunderstood what you are trying to achieve, in 
> this case you need to be more specifc :-)
> 
> My only guess here would be: Even with data inline you need to 
> generate a store for Treepanel to work. But I might be wrong. Again, 
> why don't you create a store?
> 
> Best wishes
>  Malte
> 
> 
> Am 28.04.2011 um 11:09 schrieb gilles dolet:
> 
>> Hi Malte,
>> We made some progress but we still have problems to integrate sencha 
>> with ]po[. We are working on version 4, and the current status is the
> following:
>> 	-We are able to create a json file using TCL and timesheet_task,
> this
>> is not totally finalized, but I think this will be ok soon.
>> 	-The sencha tree is now integrated in ]po[ based on dynviews, 
>> dynfields
>> 
>> We lost a lot of time on the following problem which is still open, 
>> and where would help is welcome:
>> 	-Instead to create a json file and push it to sencha, we would like 
>> to use the "data inline" which should authorize to push data to 
>> sencha without file. The following link is the topic posted by Vincent.
>> 	
>> http://www.sencha.com/forum/showthread.php?131529-Data-inline-with-Tr
>> e
>> e.Pane
>> l
>> 	
>> http://stackoverflow.com/questions/5802350/treepanel-with-root-childr
>> e
>> n
>> 
>> Did you already worked with "data inline" ? Your advices are welcome 
>> Regards Gilles
>> 
>> 
>> 
>> -----Original Message-----
>> From: Malte Sussdorff [mailto:mal...@co...]
>> Sent: mercredi 20 avril 2011 09:30
>> To: gilles dolet
>> Cc: vin...@pr...; 'Klaus Hofeditz'; 'Frank Bergmann'
>> Subject: Re: Gantt Libs
>> 
>> Hi Gilles,
>> 
>> I would favor the option to use the im_dynfield_id (or 
>> im_dynfield_attribute_id, to be precise) for real dynfields, as you 
>> can then have permissions working. E.g., if the user does not have 
>> view permission on the dynfield, then even though the view defined 
>> this, it is not viewable for the user. It also saves you from the 
>> trouble to maintain permissions on the dynfield and permissions on 
>> the dynview column (with visible_for). Dynfields may or may not be 
>> editable,
> according to the dynfield_type_attribute_map.
>> 
>> For all the computed fields (e.g. Earned income on a project) you 
>> would use the datatype and variable name. Note: You can't save / edit 
>> a computed value. Therefore we don't need a dynfield for this. We 
>> just need to know how the variable is called (in whatever is 
>> providing the ajax STORE, usually the same name as the variable in the
.tcl code).
>> 
>> As for the table_name + field_name, you already have that with the 
>> extra_select, extra_from and extra_where clause of the column. So no 
>> need for that. And even for saving, I would highly discourage you 
>> from manually saving. I like reusing Frank's code, so I would use 
>> probably reuse /intranet-timesheet2-tasks/new for saving with a 
>> return_url back to your own ajax page. Do you use the 
>> im_timesheet_task_new_redirect to branch of your own AJAX code to 
>> make it compatible for ]project-open[ ? If yes, then you would have 
>> to ignore this redirect when the form_mode is I think submit, but I'm 
>> not entirely sure. If this sounds like garbage to you.... no worries, 
>> I can try to explain
> better :-).
>> 
>> You could add the editable_p into the Ajax Configuration, e.g. by 
>> stating something like "editor:none". I haven't really thought about 
>> how to reuse the ajax_configuration column which Klaus introduced, so 
>> maybe the better way is to really have editable_p as a new column.
>> 
>> So, in total you have these additional fields:
>> 
>> - im_dynfield_id references im_dynfields(attribute_id)
>> - editable_p
>> 
>> And for displaying non edit fields:
>> - datatype references acs_datatypes(datatype)
>> - variable_name
>> 
>> Best wishes
>> Malte
>> 
>> Am 20.04.2011 um 09:03 schrieb gilles dolet:
>> 
>>> Hi Malte,
>>> So in the dynview we will then have the Name of the column, the 
>>> widget to use (and then deduct the datatype + defition combobox ....).
>>> 
>>> I think we need to add 2 extra fields to the dynview, editable (yes 
>>> /
>>> no) and  table_name+field_name.
>>> The last one could be used to identify which field/table to update 
>>> after a value has changed in the grid.
>>> 
>>> What do you think,about that proposal ?
>>> Regards,
>>> 
>>> -----Original Message-----
>>> From: Malte Sussdorff [mailto:mal...@co...]
>>> Sent: mardi 19 avril 2011 17:46
>>> To: gilles dolet
>>> Cc: vin...@pr...; 'Klaus Hofeditz'; 'Frank Bergmann'
>>> Subject: Re: Gantt Libs
>>> 
>>> Hi Gilles,
>>> 
>>> I don't make a connection between dynfield and dynview (yet). This 
>>> is on my todo list, though I would not mind some encouragement :-).
>>> 
>>> This being said, I updated dynview_columns to include a datatype and 
>>> a column_name. The column_name is the name of the variable which 
>>> contains the value (so you don't have to parse rubick_tcl to guess 
>>> what that variable might be). The datatype is the widget to be used 
>>> (I could have called it widget, but datatype is more in line with
ExtJS).
>>> This at least allows us to define the type of display to use in ExtJS.
>>> 
>>> Yet, as I said, I haven't gotten any further there due to lack of time.
>>> Ideally, as a first step, you would extend im_dynview_columns with a 
>>> column "im_dynfield_id" which references
>>> im_dynfield_attributes(attribute_id) and therefore have your 
>>> connection. But don't ask me how you create the end user interface 
>>> for
>> mapping these.
>>> 
>>> Once you have that link, you can query the sql_datatype and the 
>>> tcl_datatype from OpenACS. Additionally you can see what kind of 
>>> widget is being used and translate these widget's information into a 
>>> ExtJS Combobox. It should be pretty easy to write a procedure to do
this.
>>> 
>>> Do not make the mistake of using the same name for dynfield and 
>>> dynview column and rely on it, as you can change both with the UI.
>>> Use the approach mentioned above.
>>> 
>>> I hope this helps you a little bit along.
>>> 
>>> Otherwise I will be working on this most likely over easter, so if 
>>> you have Skype we could chat on Monday or Tuesday, even with your 
>>> developer. You can ask questions in French (or Frenglish, might be 
>>> easier :-)), as long as I can answer in English, as I understand 
>>> roughly
>> 60-70% of written french.
>>> 
>>> Best wishes
>>> Malte
>>> --
>>> 
>>> Malte Sussdorff
>>> 
>>> cognovís GmbH
>>> Schrödersweg 27
>>> D-22453 Hamburg
>>> Mobil:   +49 (0)151 / 230 33 826
>>> Fon:      +49 (0)40 / 386 60 521
>>> Fax:      +49 (0)40 / 386 60 523
>>> www.cognovis.de