I did briefly use that library, but it's built against an older release of
MR and isn't particularly well crafted... I would instead suggest rolling
your own implementation built for the needs of your app - also it really
depends on wether you're building an RIA with ExtJS (i.e. viewports, layout
etc.) or just taking advantage of their forms and controls within a fairly
standard app.

I've recently been working on quite a large MR/ExtJS app, and to be honest I
think considering the size of the JS files you end up with after a while I'd
be more inclined to not have each client seeing a slightly different version
of the javascript (and thus potentially missing out on caching opportunities
i.e. you cant off load all your javascript to a seperate host to improve
load times) - unlike sites I've built with jquery (which have miniscule
ammounts of actual code) our javascript is around 2mb in size and growing
every day.

As for disabling/enabling toolbars and other parts of the application I went
for a couple of options, first was just having a top level initialize
function (in javascript) that could be passed a bag of options, and handled
setting up the viewport/panels/layout etc. as well as storing those options
for other components to access.  On the controller-side of the equation we
just have filters on the controllers/actions which check the current users
permissions (in Rhino Security no less) and sticks them into a
Dictionary<string, object> within the PropertyBag... The controller can then
optionally grab the options from the property bag and update them if
required (i.e. for more complex scenarios) and then eventually the layout
will grab those options and render them into a json object passed into the
initialize function on document ready - I prefer this being rendered into
the page itself rather then included as a seperate generated JS file, makes
debugging easier.

That dealt with stuff that was not context sensitive..  for anything that
was context sensitive I just had empty toolbars and then made ajax calls to
the server, passing over the context (i.e. item selected in a tree view for
a right click context menu / toolbar) which would return an array of the
options/commands to be displayed, which I would then loop through
interpreting the "type" of the option and converting it into a toolbar
button / menu item with an appropriate event handler etc. - this works well
(better then considered, given my fears of latency on the user's experience)
- and you also reduce the ammount of duplication/repetition in your
javascript (I wouldn't recommend spitting actual ExtJS json out of your
action's though, that's just shifting the burdon of repetition over to your
controller).

In some cases I also just pass across a set of scope rules i.e. for nodes
X,Y & Z this button is enabled in the treeview, otherwise disabled -
especially useful for toolbars where all the buttons are always on screen...
but just enable/disable based on the context.

Another thing to consider is wether your app is going to even reload the
page - there is obviously the opportunity with ExtJS to just load content
etc. into panels and submit your forms via ajax (which is the default) - in
which case pulling the set of available permissions etc. from the server
asynchronously makes even more sense - if you go down this route then having
a set of helpers etc. for ExtJs becomes less and less useful, as most of
your forms will be defined in javascript.

On Thu, Mar 12, 2009 at 12:21 AM, Wayne Douglas <[email protected]>wrote:

> Has anyone used this:http://code.google.com/p/mr-extjs-helper/
>
> w://
>
> 2009/3/11 Wayne Douglas <[email protected]>
>
> But I'm thinking about doing stuff like this~:
>> <code>
>> new Ext.Toolbar({
>>             text: '<u>F</u>ile',
>>             iconCls: 'bmenu',
>>             hidden: false,
>>             menu: new Ext.menu.Menu({
>>             items: [
>>                 #if($IsExportPermission){
>>                     id: 'excel',
>>                     text: '<u>E</u>xcel',
>>                     hideOnClick: true,
>>                     handler: function() {
>>                         document.location =
>> 'data:application/vnd.ms-excel;base64,' + Base64.encode(grid.getExcelXml());
>>                     }
>>                 }, #end
>>                 #if($IsPreferencesPermission) {
>>                     id: 'pref',
>>                     text: '<u>P</u>references',
>>                     hideOnClick: true,
>>                     handler: function() {
>>                         Irm.UI.Dialogs.Preferences.showDialog();
>>                     }
>>                 }, #end
>>                 #if($IsPreferencesPermission)  {
>>                     id: 'sec',
>>                     text: '<u>S</u>ecurity',
>>                     hideOnClick: true,
>>                     handler: function() {
>>
>>                     }
>>                 },#end
>>                 #if($IsAdminPermission) {
>>                     id: 'admin',
>>                     text: '<u>A</u>dmin',
>>                     hideOnClick: true,
>>                     handler: function() {
>>                         window.location.href = 'http://' + location.host
>> + (settings.siteroot != '' ? settings.siteroot : '') + '/admin/index.rails';
>>                     } }, #end{
>>                     id: 'btnhome',
>>                     text: '<u>R</u>eports',
>>                     hideOnClick: true,
>>                     handler: function() {
>>                         window.location.href = 'http://' + location.host
>> + (settings.siteroot != '' ? settings.siteroot : '') +
>> '/reportviewer/index.rails';
>>                     }
>>                 }]
>>                 })
>>             })
>> </code>
>>
>> So the logic exists as part of the JS and then all the browser gets is all
>> the browser is meant to get.
>>
>> This was typed as an example in the email so don't expect that stuff to
>> work :)
>>
>> w://
>>
>> 2009/3/11 Ken Egozi <[email protected]>
>>
>> anyway it should not be in the view (NV) imo. that kind of a logic require
>>> a controller (either an MR one, or a POCO)
>>>
>>>
>>> On Wed, Mar 11, 2009 at 1:02 PM, Ken Egozi <[email protected]> wrote:
>>>
>>>> what about an IHttpHandler to serve the js files?
>>>>
>>>> /script.ashx?a,b,c,d
>>>>
>>>> will combine (and compress?) the files, and will only take the ones that
>>>> the current user/scenario allow for
>>>>
>>>>
>>>>
>>>> On Wed, Mar 11, 2009 at 12:54 PM, Wayne Douglas 
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi
>>>>> I'm trying to figure out how to secure an online app by only serving
>>>>> the JS the user has access to. I.e. - instead of simply disabling/hiding a
>>>>> menu button, I'd like the JS that creates that button to never be printed.
>>>>>
>>>>> I was thinking about setting the *.js files to pass through the
>>>>> monorail pipeline and, with some NVelocity logic, limit the JS that 
>>>>> actually
>>>>> gets sent to the client.
>>>>>
>>>>> Does anyone know how to do this, if it's been done/is possible or, if
>>>>> there's a better way?
>>>>>
>>>>> I'm using EXTJs/Monorail/NVelocity in a very large/complex application.
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>
>>>>> w://
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ken Egozi.
>>>> http://www.kenegozi.com/blog
>>>> http://www.delver.com
>>>> http://www.musicglue.com
>>>> http://www.castleproject.org
>>>> http://www.gotfriends.co.il
>>>>
>>>
>>>
>>>
>>> --
>>> Ken Egozi.
>>> http://www.kenegozi.com/blog
>>> http://www.delver.com
>>> http://www.musicglue.com
>>> http://www.castleproject.org
>>> http://www.gotfriends.co.il
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>>
>> w://
>>
>
>
>
> --
> Cheers,
>
> w://
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to