> The application that I'm targeting is similar to IPMI remote login but a more > complex version. Depending on the state of the host/hardware we might have to > juggle different fields. So it's best to handle that in code rather than > writing several different bxmls.
Okay, got it. I can see how that would be hard to handle in bxml. > Also what if someone tampers the bxml? Interesting security question.... But, along that line, if someone is really interested in hacking your application, what's to prevent them disassembling the byte code back into Java source and changing it that way also? My point being that if there is a significant security risk if someone were to change the bxml (presumably they are in your packaged .jar file, right?) then you probably need to implement some other checks somewhere so that the application can (at least) detect if things have been tampered with since the .jar file was built? ~Roger -----Original Message----- From: Josh R [mailto:[email protected]] Sent: Wednesday, August 08, 2012 12:36 PM To: [email protected] Subject: Re: How to block UI input to a disabled/busy TreeNode On Wed, Aug 8, 2012 at 3:21 PM, Roger L. Whitcomb <[email protected]> wrote: >> Depending on the node-state, the menu might even be dynamic. But cases where >> the node needs to be completely disabled it's just easier if the base >> library handled that. That way we can also avoid replicating that code in >> every user's application. > > Got it. That's why I suggested filing a JIRA issue for an improvement. > Thanks for that. > > Just curious -- what is your reason for writing 100% Java code? Our > application uses ~100 bxml files and many are dynamically chosen. We found > it easier to write even little bxml files for stuff rather than use Java code > (if possible), although there is a bunch of pure Java code in some cases too. > So, I was wondering what got you to the point of wanting only Java code? > Just filed it(Pivot-867). The application that I'm targeting is similar to IPMI remote login but a more complex version. Depending on the state of the host/hardware we might have to juggle different fields. So it's best to handle that in code rather than writing several different bxmls. Also what if someone tampers the bxml? >>100% pivot-code will also jump start developers relatively quickly and might >>trigger adoption at a higher rate. > > Agreed, which is why I was wondering about your use case to consider how many > others might be in the same place. > > Thanks, > ~Roger > thanks
