Hey
Thanks for an excellent reply. It's a full fledged ExtJs Accounting App for
the gov with > 2MB uncompressed JS and counting!! They want all sorts of
stuff added to it and love it - Extjs + Castle are sooooooo good!!
The fact that it deals with accountancy including HR data means we can't
take any chances. I need to stop the chance of even a secured URL reaching
the client and so we need to have control blocks inside the JS - or as you
said maintain different versions - which is not feasible.
All said and done - the way you specified is basically the route we're
taking except I'm going to use parser tags inside the JS and feed all the JS
through a handler which can then stream only the JS I want to the client
based on the logic specified with the parser tags.
That way we can do stuff like (not 100% on the syntax yet but to
illustrate):
<code>
new Ext.Toolbar({
text: '<u>F</u>ile',
iconCls: 'bmenu',
hidden: false,
menu: new Ext.menu.Menu({
items: [
##IsAdmin{
id: 'excel',
text: '<u>E</u>xcel',
hideOnClick: true,
handler: function() {
document.location =
'data:application/vnd.ms-excel;base64,' + Base64.encode(grid.getExcelXml());
}
}, ##end
##IsAdmin {
id: 'pref',
text: '<u>P</u>references',
hideOnClick: true,
handler: function() {
Irm.UI.Dialogs.Preferences.showDialog();
}
},##end
##IsAdmin{
id: 'sec',
text: '<u>S</u>ecurity',
hideOnClick: true,
handler: function() {
}
},##end
##IsAdmin {
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>
Cheers
w://
2009/3/11 Alex Henderson <[email protected]>
> 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://
>>
>>
>>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
