Joseph Marques - 21/Jul/08 10:31 PM interesting feature request. i agree that dynamic config elements make config stuff even more powerful, but i'm not sure i see the ROI for supporting cascade rules across fields. the flow is already rather complex: before config ui renders, it realizes that it needs to query information from the agent-side, so it makes distinct requests to it, which in turn potentially query the managed resource for information, information is passed back up to the server-side, and after all responses are known the config ui component can finally render the response. some thoughts / questions: * if we don't support cascading rules, then it's quite easy to cache the dynamic results after they are gotten from the agent the first time. the page will only be slow on initial load, and after that the user can edit lists/maps as well as perform any other multi-page flows without needing to talk to the agent again. * is there a way to pre-load this data before the user goes to the config ui page, maybe at import-time, or some other sufficiently advanced time? i'm guessing no because dynamic properties can be based off of just about anything right? * is there a way to make this a complete server-side implementation, where the user given access to some sort of restricted data model through a simplified, dynamic config property DSL (similar to what the embedded CLI might look like)? * how should this work if the agent is down, or the manage resource that the agent needs to talk to is down? in this case, i think the UI would either fail to render, or would render an empty list - both of which aren't very helpful...unless of course we could pre-fetch this data when we know it was available, or if the implementation was completely server-side.