Inline response > No, the client would > 1. get the data > 2. pass the data to the component. > the component will manage how to display the data. as for input, the > same is true. you could pull the user input from the component and > then do whatever you want to it.
Some of the control fields are dropdowns with information like countries or other generic information. Still sounds like duplication if it will be the same for all uses. This is where the line of DRY and YAGNI meet. At this point, the fields are expected to be the same and if they're not then there is no point in the control anyway. > > Keep in mind that this control would be accessed from multiple > > applications > > Even more reason not to tie it to a specific data access methology Not if the fields will be the same regardless of the application. Why force every client to access the same data for the control when it can be done once within the control. > > > and the data would not change for the different > > applications. It is standard data not specific to any one application. > > Then why is a database needed at all? I meant fields, rather than data. My fault. > > > It would seem to me to add quite a bit of duplication to bind the > > control from every client if the display data will be basically the > > same. > > the application using the component is not binding the data. it's only > retrieving the data. the component is binding the data (DRY) Yes not binding but accessing which will be repeated across all applications that use the control. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
