i am doing a project in which i have 3 classes (lamp, clock and TV) now,
i am making a GUI Application which will allow users to add lamps, tv's and clocks to a 3.3 grid panel,
in terms of validation, one of the constructors of the Clock class allows the user to initiate a Clock with hour minute and second parameters passed into it, as well as various setters
would it be best to have the validation inside these classes (i.e. ensuring user cannot make a clock which reads 24:01:01 etc) or is it advisable to have the validation at the GUI level i.e if asked to enter a time to initiate the clock, if it is wrong, simply display the panel again until valid input is applied.
based on experience, which is the best advisable way to do this?
(i am a first year Computer Scientist studying java, bare that in mind when responding as im not familiar with deep technical methods)
Thanks,
You would want validation on both levels.
You want validation on the model side (the Clock class) to avoid invalid data in your model.
However, to offer a good user experience you also want validation in the UI so that the user immediately sees that his/her input is invalid and not has to wait until his/her input reaches the model.
Compare it with a web application: you want validation on the front-end to offer quick feedback to your user. You also want server-side validation to avoid that somebody bypasses your UI and inserts invalid data in your model.
Related
What I mean by 'conditional' privileges is, for example: Say we have Event e. The user who CREATED Event e should be able to delete Event e and invite additional users to Event e, but only that user.
From tutorials I've seen, permissions and roles seem static, for example:
Doctor has a role doctor, with permissions x, y and z, but that is it...pretty static.
Is there a simple way to conditionally manage permissions with Spring Security?
Or would this be something better suited for the front-end? For example, the view would show a 'delete event' button only if the resource data for that particular Event confirms that the Event creator's ID is in fact the same ID stored in session memory/keychain/whatever for the currently logged in user, type of thing.
Thanks
First of all,
Or would this be something better suited for the front-end?
...show a 'delete event' button only if...
NO. Not as a reliable line of defence, no.
Well that probably depends on a tech stack, architecture etc, but as a rule of thumb, you shouldn't do it. I didn't write servlets/jsp, but I used spring security in a rich client (swing) application and even though we had all the control (I mean, we could guarantee that user cannot access some function no other way than clicking a button), we secured our models, not the gui.
You shouldn't be able to call Entity#delete no matter how you call it - via button click event or calling it directly in a test. In case of web application, imagine you don't display a button, but an attacker knows that button leads to example.com/entity?action=delete URL or something like that, he could access it directly even if you don't render the button.
With regard to the main question, spring security, roughly speaking, has two parts: RBAC and ACL. What you need seems to be the ACL part. Read some howtos and articles about domain security, it's a pretty complex stuff, but it can be suited for your needs for sure (with some effort, of course). What you described in a first paragraph may be achieved easily because every object has it's owner and it can be exploited.
Also, here's a good advice.
Edit: just to clear things up for future visitors. Point was: there should be some logic on the front-end, but it must not be the only security logic. Of course there's no need to clutter UI with buttons leading to functions you can't access.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
From week I have been searching of a true explanation and implementation of MVC using java, but something i have noticed is that every one implement it differently, so I would be grateful if you give me a useful link or e-book about it, and I need these questions to be answered :
How to inform the modal of the changes happen on the view, since the modal is observable adnd not observer ?
How to inform the view of the changes happen on collections (adding an item to an arraylist), because to add an item this will be happen on the controller handler and the controller is not observable.
Is it a must to work with MVC in the big projects.
The basic idea is:
The trigger for change can be either the controller
(=response code for user inputs, such as keyboard/mouse clicks), or application
decision. E.g. if you have a text field showing a price, the trigger to change it could
be explicit user typing, or a message from the bank.
each such trigger updates the model (and the model only).
In my price example, it would change the model (that backs the text field).
On change - the model fires events, which cause the view to re-render
Thus, to your first question: there's no need to "inform the model that changes happen on the view". The view shouldn't change on its own. The closes thing is keyboard/mouse clicks, that would invoke the CONTROLLER.
To your second question: "how to inform the view of the changes happen on collection" - the collection should be in the model. The controller would then do "model.addItem" which would fire an event for the view
Regarding the use in big projects... you'd probably get different opinions on it.
"Atomic" components would most likely follow this pattern strictly (button, textfield, or similar custom components). The debate would be about larger scales with complex/compound data. E.g. if my main logic resides on a database, how to I inform various screens that something changed. Both the screen and the database hold complex compound data (e.g. user plus his product recommendations plus shopping cart), and you need to decide on the granularity of events : on some simple applications I settled for the application layer sending 'Entity-level events' (such as 'user changed', 'product changed') to which the UI layer registered directly, so it wasn't 100% classical MVC. On other cases I took the trouble to build a compound Model that exactly reflects the screen data.
For the first part, I advise you to start at Wikipedia page on Model–view–controller. You will find a decent explain and other links.
For your first questions, you simply have to think about the workflow. The interaction with user occurs is the view. Then on an action of the user the controller takes the input, optionnaly reformats and passes it to the model in a format known to the model. In theory, the model then updates the view (in web applications, the controller collects data from the model and passes it to the view, so the update model -> view is indirect).
For the second, if you are in a situation where the model can directly update the view (Desktop application or specialized components such as java applets) no problem. If the model cannot directly update the view (typical in web applications), the update will be visible on next interaction. And in fact it happens exactly this way, when you see a web page with gauges displaying values constantly up to date : the browser is instructed via javascript or html meta tags to refresh its state at short time intervals. But when you say to add an item this will be happen on the controller handler, it is only true is this is caused by an interaction from the user (and the view knows it has to update its state, or is instructed to do so via the controller). But the model can be modified by many other ways, interaction from other users, real time probes, back office operations, etc.
The third question is a bit a matter of opinions. What is true is that separation of concerns is recognized as a good design because the different layers can be developped and tested independently (ot a certain extend). That separation allows to change technology in one layer without changing the others (even if this is often theorical). But IMHO the greatest benefit is that you have plenty of frameworks implementing MVC pattern. Choose one, and the greatest part of boiler plate code will be offered by the framework without you having to write and test it. All that giving a reduction of developpement time and of possibilities of mistakes.
My conclusion will be that (like others said in theirs comments) what is important is understanding the theory and the theorical benefits of MVC patterns and separation of concerns. Then depending of what you have to develop and you environment (technologies knowned or allowed) choose a framework that will exempt you to write boiler plate code, and spend the saved time to carefully analyze what all that is for, and what users expect.
Is there a Java utility class to help with data management in a desktop UI?
I am writing a UI to configure a network device that will be connected to the serial port of the computer while it is being configured. There is no web server for my application.
The UI has a large number of fields (50+) spread across 16 tabs.
I will write the UI in Java (Java FX?). It should run inside the browser when launched, and issue commands to the network device through the serial port. A UI has several input fields spread across tabs and one single Submit button. If a field is edited, and the submit button clicked, it issues a command and sends the new datum to the device, retrieves current value and any errors. so if input field has bad data, it is indicated for example, the field has a red border.
Is there a standard design pattern or Java utility class to accomplish the frequently encountered, 'generic' parts of this scenario? lazy loading, submitting only what fields changed, displaying what fields have errors etc.
(I dont want to reinvent the wheel if it is already there). Otherwise I can write such a class and share it back here if it is useful.
You need a data model : a set of classes with different kind of relationships (UML design may help).
You can learn more about MVC pattern.
Java encourages the Model Control View pattern for separating the levels of responsibility when it comes to the management of data.
Essentianlly the idea is to provide a model that a view can show to the user. The model doesn't care how its displayed nor does the view care about how the data is managed, they simply have an agree dead interface through which they can communicate
I was wondering whether the use of a decorator pattern is good in case I want my model ("M part" of MVC) to raise Exceptions depending on their origin. I explain myself.
I have a class called Game which is a part of the Model. I have two Views : a GUI and a command line. I want my model to raise an Exception for command line view when the user enters a character instead of a number (for example). Of course I don't want this Exception to be handled by the model as it "belongs" to the command line and not to the Model itself.
To encapsulate those two different behaviors, I plan to decorate the Game class with two classes : CommandLineGame and GUIGame which have only one attribute : Game and handle their own kind of Exception. Is it a good idea ? Is there a better one ? The problem of such a solution is that every model class raising Exception depending on its origin has to be decorated...
What you are describing in the example is "input validation". Strictly speaking*, this belongs in the Controller ("C Part") of MVC.
The separation of concerns for MVC decomposes as follows:
View is there to 1) present a UI for the user to evaluate the state of the program (Also, what your program looks like visually) and 2) to receive the user's expression of intent (receive raw instructions on what they may want to do)
Controller is the actual interpreter of these "actions" or "intentions" from the user. It decides what it means for a user to click a particular button and what to call in your model. It decides whether a particular input actually makes sense given context from the UI (and in some case from the model).
Model should be View/Controller agnostic (Meaning the model should have no knowledge of the View/Controller). It should only be about the internal representation of what you are trying to "model". The advantage of doing it this way: you can have many different UIs, or change your existing UIs without affecting the model.
Overall, the idea is to lower coupling and increase cohesion.
I hope that makes sense =)
Depending on the language / framework, the lines between MVC components get blurred a bit. Some idioms will lump most of Controller into the View, but the encapsulation of logic should stay relatively similar.
*In practice, for defensive programming, input validation is done twice for mutual suspicion: they are broken down into client-side mediation and server-side mediation:
In this case, the Model part should handle the "server-side" mediation: it should check that the arguments passed to its functions actually make sense before proceeding.
Similarly, the Controller/View part should check the input as part of "client-side" mediation, so that it can warn the user right away, without passing it back to the model, and then eventually back to the view.
It will keep your code very clean, something i like a lot from an academic perspective.
On the other hand do you need to introduce this kind of design complexity for a simple problem like this?
So, if you need the code to be clean... GO for it.
I'm helping to build a GWT application for a client and rewrote most of the stuff to work better, shorter code, faster, etc. However in all the GUI application I've worked on (not so many really) there comes a flexing point where you just have to put a lot of rules and move logic from the listeners to some common mediator. Then some times this could get an ugly mess so you whatever small think you need to do in the listener.
Let's take an example:
form with 10-20 fields
two exclusive radio control about half of the state of the other fields (enabling, validation, input limits)
three exclusive radio controls control again almost the same fields, but in a different way (affecting calculations, enabling); they are also controlled by the above
4 or so number fields are validated on the fly depending on the previous selections and some real-time data object; they can have upper/lower limits, be enabled/disabled
one drop-down box controls the next 6 or so controls - displaying/hiding them, modifying validators
some checkboxes (shown by the above combo) activate some input fields and also determine their validation algorithm
While everything is up an running, without known bugs, there are a few coding gotchas that really bother me:
code is spread among listeners and some mediator methods.
loading the form with some preset values presents its own challenges: like data objects that might be available or not, data objects that might alter their state and subsequent field behaviour
some fields are having a default value set and this should not be overwritten by automatic filling, but if the data objects are not there (yet) then they will need to be filled eventually when the later become available
form cannot be submitted if any of the fields are not validated
My approach:
identify which fields share a common afair and move code into one place
each radio group shares a single listener implementation between its radios
default form filling is deferred until the live data is available (as much as possible) and as a result it gets called multiple times
each action has a call to a common validator method
the validator runs through all the fields in the form, calls their validators (which highlight all errors) and returns a single boolean
each relevant keypress or mouse action, data change it gets deferred to be called after 250ms from the last call; this means first call just places the validator as a delayed action, subsequent calls reset the timer
Ok, it doesn't make any sense to dwelve into more details but I'm more upset about the fact that there is no clear separation between visual actions (enabling), data actions (setting form field values), field listeners, retrieving form values and live data listeners.
What would be a good approach/pattern (next time maybe) to make sure that MVC get separated and lends itself better to maintenance? I know this is not a typical question but I've read every documentation I could get my hands on and still did not find some helpful answer.
I'd move closer towards MVP than MVC. It's clearly the way Google intends to go, so adopting it will probably mean that you're able to go with the flow rather than fight the current.
How does this affect you? Well, I believe you should accept that a tidier implementation may involve more code: not the 'shorter code' you were hoping for. But, if it's logically structured, efficient code the Google compiler should be able to trim lots out in the compiler optimisation phase.
So, move as much of the logic as you can into the model layer. Test this thoroughly, and verify that the correct level of page reset/tidying happens (all of this can be done with plain JUnit, without any UI). Next, use your Presenter (Activity) to tie the View to the Model: handling the interactions, populating the fields, etc.
you can divide a Huge class in different classes bu dividing the GUI in different JPanels. All the panels are implemented in different classes extending JPanel. Guess that would help you.