|
Hello:
I need to build a reporting tool that can read an xml file (which is the data output of a piece of hardware). The report would be populated with the read-only data (output from the hardware), but there also needs to be a comment field added to the report template that the user can data enter into and then the whole thing needs to be saved as a filled in report instance. I was thinking .pdf.
1) One way I see this application is.: I would create an xsl file for the template. The xsl file would be merged with the xml file to create the report.
The data is sensitive so I don't want the data in the cloud.
It will be available locally via a flash drive.
If I did it this way, I envision a local web server to be started on the client since a browser can not read a local xsl or xml file without security issues.
So, this design is kind of a local web application.
2) Another way is to create a desktop application, but then there are distribution issues and runtime issues, if it's a C# application. The other alternative for me is a Java Web Start application.
Either way, I do it, I think it would be easiest to have the data/template be displayed on the screen so the user can enter the comments into a field and then have another tool save to a .pdf.
Any ideas or has someone done something similar where they would be able to share what worked for them?
Dan
|
|
|
|
|
Just create a PDF with a comment field the user can edit. The user can then add a comment and write-protect the PDF / comment field if they want to.
(Later on you can start getting "fancy").
|
|
|
|
|
Background
In my workplace there is a debate on two backward Compatibility (BC) implementation approaches. I am not talking on the question if our code need to be BC, this is given and a consensus. The question is how to do it in the code level.
Lets assume that we have CodeA with inputA and resultsA and newer evolved code CodeB.
The Code, of course, knows to identify if the input is A or B.
Lets assume that ~20% of the code functionality was changed.
Lets assume that each version footprint is 1Mb.
The BC requirement is that CodeB with InputA will provide ResultsA.
Strategy 1 – if in the top + code duplication
One approach which is led by the more agile side says:
When I evolve my code from A to B, I don't want to think about BC. I will do it as if this was the very first (ever) code. Then in the last stage I will wrap both CodeA and CodeB by a switcher in the most higher level that will call the full old codeA when he sees InputA. I know it is code duplication but binary size is no concern these days and my newest code is always clean and not carry the old deprecated code. When code A will not be necessary anymore few years from now I will throw it away and will be left with B (or C, D ...). I know this is not elegant but time to market is more important and again even if I have 10 versions together it is only 10Mb.
Strategy 2 – if in the fine grained bottom level
Second approach which is led by the more classical "by the book" SW engineering says:
When I evolve my code from A to B I will put a BC handling (if or whatever) on the fine grain lower level changed functionality (functions, methods, lines …). After all it is just 20%. I know it is tiresome and my one code will be with ugly BC handling on many lines but I have at least one consistent and compact code and not huge code with A,B,C,D,E full versions inside.
What do you think? Who is right? Will be happy to hear why, cons and pros + ref to reading on this subject.
|
|
|
|
|
Approach 1 is not DRY, and would require maintaining similar code. Meaning any update will have to be done in multiple places, creating multiple places to fail and test. If you make it a strategy, you'll get a large codebase with duplicated functionality. Will become hard to maintain over the years.
Make it SOLID.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy, Thanks for the comment.
However, Guy#1 will say. I am DRY! I am only updating the latest version. In a matter of fact I will never refactor the older code because I want it to work EXACTLY!! like it did when it was the most updated. This is "rollback by design".
proper disclosure - I belong to the second group but want to challenge what I've been told and "raised on".
|
|
|
|
|
Lior Cohen wrote: I am only updating the latest version That may be the idea, but sooner or later there is a change that needs to be in both versions. If you have a duplicate, it is not DRY.
Lior Cohen wrote: In a matter of fact I will never refactor the older code Even if you never refactor, never change requirements, if there's a bug that needs fixing that gets discovered later, you'd be fixing minimal two places.
Don't tell me it won't happen, it happens continuously.
Lior Cohen wrote: This is "rollback by design". No, it is being incompatible with your older version.
Good compatibility means, among others, that data-files can be used by both versions. Meaning the older version will need to ignore extra data and the newer version needs to check whether it is there before acting on it. If your new version uses a new layout and converts all, then you might no longer be able to "rollback by design" without destroying the users' data.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: you'd be fixing minimal two places.
I think i need to describe my system a little, as I don't understand why you claim I need to fix a bug in both places.
My code is an image processing module (no UI).
The input is an image and a parameters bundle we call a "recipe".
one of the recipe parameters is the version of this recipe.
The recipe is created from the same context so it always created with the version of its creator.
In pseudo code is
out = process(in, recipe)
Approach 1 implementation will be like this:
out = process(in, recipe) {
if recipe is of version Jan {out=process_Jan(in, recipe)}
else {out=process_Feb(in, recipe)}
}
Now suppose there is a bug on process_Jan (the old). Fixing the bug will change the results anyway so the customer had 2 options
1. Stay with the Jan version including the bug (bug compatibility )
or
2. Move to a new March version with bug fix but with different results.
The bug fix will be change the code like this
out = process(in, recipe) {
if recipe is of version Jan {out=process_Jan(in, recipe)}
else if recipe is of version Feb {out=process_Feb(in, recipe)}
else {out=process_Mar(in, recipe)}
}
so here I changed the bug only on Mar and not in all places.
Please try to explain on this example.
modified 10-Oct-15 10:05am.
|
|
|
|
|
Lior Cohen wrote: Please try to explain on this example. That's a nice little example which is severely limited in scope. As you can see, 'proces_A' is not named after februari (what year?), so it may already be confusing to the casual reader.
Sh*t starts happening once there is a dependent method; imagine calling "DoSomethingWithImage" from process_Jan. It needs a bugfix too. Now all methods using that will need to be changed; one path to guarantee the old behaviour, one for the new functionality.
I'd recommend using inheritance, not a bunch of if-switches.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The vendors I currently work with have a very simple versioning policy:
If you want support and a fix for a previous version, you first need to upgrade to the latest version (for free). The upgrade is a no-brainer; in some cases done automatically. (A version# is what kicks anything off if it does not match what is currently available online).
(If you want to be cagey, call the upgrade a "fix"; who's to say when a fix becomes an upgrade).
|
|
|
|
|
Hello Sir,
Thank you so much for post this architect strategy of web development .
by VAni,
://www.3d-architectural-rendering.com
|
|
|
|
|
i want to increase background size of .woo-feature and .woo-about in page but after add the CSS the background width increased on window all browsers but its not working on MAC operating system on any of browser.
website link:- http://bowerybeachfarm.com/farm-tour/
CSS I USED:- .woo-feature{margin-left:-13%; margin-right:-13%;}
.woo-about{margin-left:-13%; margin-right:-13%;}
please give me any suggestion where i am wrong and how can i fix it.
Thanks
Gurjit Singh
|
|
|
|
|
You would be better off asking this question in the Web Development forum. This forum is for application design questions, not web design.
|
|
|
|
|
I am working above IEEE paper can anyone help me to understand above topic please help me to understand
|
|
|
|
|
What have you done with this and what don't you understand?
|
|
|
|
|
What part of the IEEE paper are you having trouble with? Elaborate on that a bit, and people may be able to better help you.
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
Hi there,
I have problem with laptop HP Pavilion dv5. When I start it, I use my user and password, but then there is a black screen, so I cant see icons, folders....
I have to use task manager to open browser as a new task.
I can access with safe mode there I can see icons, folders, etc.
I tried restore it but doesn't work. Does any one know where is a problem ?
Please help me!
I appreciate that!
|
|
|
|
|
The problem sounds like explorer.exe is not executing. type in run 'explorer' or start a new task with 'explorer'. If that works, run a virus, malware, and ccleaner registry scan, to check for problems. A
Blah blah blah... say your prays...
|
|
|
|
|
I am working on a CSS parser which requires to implement each algorithm to parse different CSS selectors. So I saw a Statergy Pattern there. Everything working perfect and satisfies the Open/Closed principle. If But now I concern about the rising number of this statergy pattern implementations. Also I am expected to include few more in near future.
I can implement this in a different method like an array of Func methods. Each Func method will encapsulate the algorithm to parse different CSS selectors. To me, this implementation is more primitive than Object Oriented approach.
Before analyzing the performace like aspects, I just want to know which one is more adaptable. It is difficult for me to judge which one is more better design. Can you please help me on this?
|
|
|
|
|
popchecker wrote: If But now I concern about the rising number of this statergy pattern implementations. Why? There's also a rising amount of code. The amount does not say much in itself - if the usage is justified, it is not bloat. If it is there just to say "look, I'm doing patterns" without adding value (there's always cost) then it is bloat.
popchecker wrote: o me, this implementation is more primitive than Object Oriented approach. A parser might be handy.
popchecker wrote: I just want to know which one is more adaptable. Which approach compared to which other approach?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
popchecker wrote: I am working on a CSS parser ...
Before you re-invent the wheel, have you seen this project[^]?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
popchecker wrote: If But now I concern about the rising number of this statergy pattern implementations
10? 1000? 100,000?
popchecker wrote: Before analyzing the performace like aspects
I would expect that profiling would determine that implementation methodology of accessing the functionality would have zero impact (just noise) for either method The functionality represented by each and the usage to which each is put would be the problem. If there even is a problem.
|
|
|
|
|
Could any one help me in order to configure team foundation server on our local machine.
Thanks in advance.
|
|
|
|
|
Hi all,
is there a possibility to get the current caption bar colors (background of caption), the button colors in the caption (normal, highlight, click) and the frame around a window (active, inactive).
GetSysColor and afxGlobalData do not give me colors, which are equal to the one of the system.
Regards,
jung-kreidler
|
|
|
|
|
I've done things wrong, I confess, now I'm paying the consequences with an endless refactoring.
I'm trying to adpopt a new working paradigm.
I'll expose a concrete case, to make myself clear.
The application is about Recipes. User adds a new recipe, the application takes the information of that recipe and calculates the time it will take to cook it. Then the data is stored on a database, so you can read it again in the future.
Paradigm i've chosen so far:
1) Recipe: object to interact with the UI only has properties:
Public Class Recipe
Public Property Name
Public Property Ingredients as list(of Ingredient)
Public Property CookingWays as List(Of String)
End Class
2) Class to interact with the database
Public Class Persister
Public Sub Register(Rec as Recipe )
End sub
Public Function GetObject(Rec as Recipe, id as Long) as Recipe
Return Rec
End sub
End Class
3) A Class Factory. I call a method of this class inserting as parameter as string and get a new object.
Public Class Factory
Public Function Instatiate(Recipe as String)
Return New Recipe
End sub
Public Function Instatiate(Recipe as String, id As Long)
Dim rec as recipe = Instantiate("Recipe")
Persister.GetRecipe(rec, id)
End sub
End Class
4) Overload methods in the Validator Class and throw an exception if something isn t correct.
Public Class Validator
Public Sub Validate(Rec as Recipe)
End sub
Public Sub Validate(Ing as Ingredient)
End sub
End Class
5) FormManager: this class takes "objects" (like recipes or ingredients) and depending of what we want to (insert new, modify existing) shows the form
Public Class FormManager
Public Function Insert(Rec as Recipe) as Recipe
RecipeForm.Action = "Insert"
RecipeForm.Show()
Dim Val as new Validator
Val.Validate(RecipeForm.ObjectInUse)
Return RecipeForm.ObjectInUse
End sub
Public Sub Insert(Ing as Ingredient) as Recipe
IngredientForm.Action = "Insert"
IngredientForm.Show()
Dim Val as new Validator
Val.Validate(IngredientForm.ObjectInUse)
Return IngredientForm.ObjectInUse
End sub
End Class
6) RecipeManager: it will do te magic, uses all the other classes
Public Class RecipeManager
Public Function CreateRecipe As Integer
Dim fac as new Factory
Dim Rec = Fac.Instantiate("Recipe")
Dim f as new FormManager
rec = f.Insert(Rec)
If Rec is Nothing Then
Exit Function
Else
Dim per as new Persister
Per.Register(Rec)
End If
Return GetTime(Rec)
End Sub
Private Function GetTime(RecipeToAnalyse as Recipe) as Integer
End sub
End Class
Now analysing the Principles:
1) Single responsability: Okey. Every class do the thing they were made for.
2) Open Closed Principle: If I'd like to add functionality tomorrow, lets say I want to add a property to the recipe which is called ToolsNeeded. It tells you what knifes bowls or microwave you need to cook it. I could make new subclasess like:
New Class
-RecipeWithTools: Inherits Recipe and adds the property ToolsNeeded
I overload new methods to this classes:
-FormManager: Shows an extra textbox where you write the tools.
-Validator: Check object RecipeWithTools has value in the ToolsNeeded property.
-Factory: Instatiate(RecipeWithTools) and Instatiate(RecipeWithTools, id):
-Persister: adds method Register(RecipeWithTools, Select): Register(RecipeWithTools, Insert): Register(RecipeWithTools, Delete): Register(RecipeWithTools, Update)
Stays the same:
-RecipeManager: stays the same because nothing was changed in calculation function. The Create Method is called with "RecipeWithTools" String so the factory knows it has to return a RecipeWithTools. The form manager knows it must show the textBox for the ToolsNeeded. The validator knows it has to check if the objects has the ToolsNeeded.
3) Liskov Substituion: In the new derived classes i could use the Recipe class instead of the RecipeWithTools and everything would be the same.
4) Interface segregation principle: Not using interfaces here, I understand I replaced them with inheritance. ¿It's Okey?
5) Dependency inversion principle: Eh... No clue.
On the other hand I think i have three layers separated here:
UI: FormManager
Business Logic: Recipe, RecipeManager, Factory y Validator.
Data Layer: Persister
Questions:
1) What do you think of the model?
2) Should I use an interface if i think that in the future RecipeManager is going to work with objects that have common things with a Recipe, but are not a recipe? If not, when would that be?
3) Can anyone explain to me how would principle 4 and 5 apply here?
|
|
|
|
|
MarkosElCojudo wrote: 1) What do you think of the model? It has more documentation than usual. It also shows that you put an effort into your design decisions
MarkosElCojudo wrote: 2) Should I use an interface if i think that in the future RecipeManager is
going to work with objects that have common things with a Recipe, but are not a
recipe? If not, when would that be? A recipe for concrete, for instance; it is rather similar. Sand, water, cement, tweedeledeet, concrete
If the recipe-making is further expanded into a hierarchy of subtasks, you could put all kinds of generic procedures in there; ingredients can vary from resources to any raw material or tool.
MarkosElCojudo wrote: 4) Interface segregation principle: Not using interfaces here, I
understand I replaced them with inheritance. ¿It's Okey? If it works for you, then yes; oke is not 'ideal', but already a better starting point that lots. I'd still recommend programming against an interface; it would give you some more flexibility during maintenance, since anything that adheres to the interface would be permissive. Do read on, since..
MarkosElCojudo wrote: 5) Dependency inversion principle: Wikipedia[^] has an accessible description.
In short, instead of having one layer depend on the other, it merely depends on interfaces. If you do expect this project to grow into multiple recipe-type's, I'd certainly recommend it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|