Removal of Registry entries created by a Web App Debugger ap - Delphi Internet Isapi-WebBroker

BorlandTalk.com
Borland discussion newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Removal of Registry entries created by a Web App Debugger ap

BorlandTalk.com Forum Index -> Delphi Internet Isapi-WebBroker

View previous topic :: View next topic

Author

Message

Enquiring Mind
Guest

Posted: Tue Mar 06, 2007 5:25 pm Post subject: Removal of Registry entries created by a Web App Debugger ap

Hi, I am a little hesitant about posting this query to this newsgroup, because its activity level seems to fall within the "almost dormant" category. Does this this says something about the uptake of Delphi Web Broker tools? The question is this. I have noticed that when a Web App Debugger application is created in D7, Delphi makes several entries in the Windows Registry. Does Delphi provide a tool for deleting these entries when the Web App Debugger application is no longer needed, and is removed from the computer? Many thanks. Regards, Enquiring Mind

Nicholas Brooks
Guest

Posted: Wed Mar 07, 2007 3:53 am Post subject: Re: Removal of Registry entries created by a Web App Debugge

Quote:

I am a little hesitant about posting this query to this newsgroup, because
its activity level seems to fall within the "almost dormant" category. Does
this this says something about the uptake of Delphi Web Broker tools?

Yes. I'd guess most developers are using asp.net or intraweb or moved onto something completely non-delphi (sorry, Object Pascal) related. For us, we are still using Web Broker apps (ISAPI) just because we haven't had the time to move to something else.

Quote:

Can't help you there, but does it really matter? There must be plenty of other apps that put stuff in your Registry without worrying to clean up after.

Cheers
Nicholas

Pim-Jan
Guest

Posted: Thu Mar 08, 2007 4:08 pm Post subject: Re: Removal of Registry entries created by a Web App Debugge

"Enquiring Mind" <Enquiring.Mind (AT) nospam (DOT) btopenworld.com> wrote:

Quote:

Launch the Web App Debugger, start the default application
http://localhost:8081/ServerInfo.ServerInfo. This will list
all registered apps. Click on "View Details", it will list
all apps with their executable name and path, whether it is
found or not and a button "Clean" to remove the application.

Pim-Jan

Enquiring Mind
Guest

Posted: Tue Mar 13, 2007 4:11 pm Post subject: Re: Removal of Registry entries created by a Web App Debugge

"Nicholas Brooks" <nbrooks (AT) infobase (DOT) com.au> wrote in message
news:45ede3c4 (AT) newsgroups (DOT) borland.com...

Many thanks for your response.

Quote:

Yes. I'd guess most developers are using asp.net or intraweb or moved
onto something completely non-delphi (sorry, Object Pascal) related. For
us, we are still using Web Broker apps (ISAPI) just because we haven't had
the time to move to something else.

I am new to the field of dynamic web site programming but my understanding

is that most of the newer technogies in vogue or being heavily promoted are
built on a foundation of CGI/ISAPI modules at a lower level. So building
dynamic web sites using CGI/ISAPI gives one maximum control, without the
fluff of the higher level frameworks. Developing compiled CGI/ISAPI web app
modules may appear a little austere in comparison with ASP.NET, but doing so
in conjunction with a visual web development tool like Dreamweaver doesn't
entail a significant productivity hit. To my mind there are significant
advantages (as well as some disadvantages, mainly related to security) in
using this lower level approach.

Quote:

The question is this. I have noticed that when a Web App Debugger
application is created in D7, Delphi makes several entries in the Windows
Registry. Does Delphi provide a tool for deleting these entries when the
Web App Debugger application is no longer needed, and is removed from the
computer?

Can't help you there, but does it really matter? There must be plenty of
other apps that put stuff in your Registry without worrying to clean up
after.

I suppose it's a matter of good order. I agree that a few extra obsolete or
orphaned entries in the Registry may do no active harm, apart from perhaps
impacting adversely on the efficiency of the system, and possibly causing
obscure security and installation problems at some time in the future. So
IMHO the general principle should be that any application installed into
the operating system should be uninstallable. Therefore any well behaved
application or development tool should generate for every Register procedure
a corresponding Unregister procedure.

Regards,

Enquiring Mind

Enquiring Mind
Guest

Posted: Tue Mar 13, 2007 4:12 pm Post subject: Re: Removal of Registry entries created by a Web App Debugge

"Pim-Jan" <just (AT) nospam (DOT) please> wrote in message
news:45efe0ac$1 (AT) newsgroups (DOT) borland.com...

Quote:

Enquiring Mind

Nicholas Brooks
Guest

Posted: Wed Mar 14, 2007 5:21 am Post subject: Re: Removal of Registry entries created by a Web App Debugge

Quote:

Many thanks for your response.

No probs.

Quote:

I am new to the field of dynamic web site programming but my understanding
is that most of the newer technogies in vogue or being heavily promoted are
built on a foundation of CGI/ISAPI modules at a lower level. So building
dynamic web sites using CGI/ISAPI gives one maximum control, without the
fluff of the higher level frameworks. Developing compiled CGI/ISAPI web app
modules may appear a little austere in comparison with ASP.NET, but doing so
in conjunction with a visual web development tool like Dreamweaver doesn't
entail a significant productivity hit. To my mind there are significant
advantages (as well as some disadvantages, mainly related to security) in
using this lower level approach.

It's interesting you are taking this approach. In my opinion the 'fluff' is what makes these frameworks so much better than starting from such a low level. Note that I'm not talking about ASP.NET, but rather frameworks such as Ruby on Rails or Django, since I have reservations with the ASP.NET approach.

I'm interested in what significant advantages you see in this lower level approach to web development?

Quote:

Absolutely Agree. I think I had let my frustrations from that day take over when I wrote my response. So apologies if I had come across as flippant.

Cheers
Nicholas

Enquiring Mind
Guest

Posted: Wed Mar 14, 2007 8:16 pm Post subject: Re: Removal of Registry entries created by a Web App Debugge

"Nicholas Brooks" <nbrooks (AT) infobase (DOT) com.au> wrote in message
news:45f740fa$1 (AT) newsgroups (DOT) borland.com...

Quote:

It's interesting you are taking this approach. In my opinion the 'fluff'
is what makes these frameworks so much better than starting from such a
low level. Note that I'm not talking about ASP.NET, but rather
frameworks such as Ruby on Rails or Django, since I have reservations with
the ASP.NET approach.

I'm interested in what significant advantages you see in this lower level
approach to web development?

The main advantages of working with compiled CGI/ISAPI modules include, as I
see them:

- There is a clear separation between static HTML and server-side code,
provided that the CGI/ISAPI code module confines itself to generating
dynamic content and plugging it into a static template .html file created by
a web designer using a tool like Dreamweaver, using for example the
TPageProducer class
- The web application developer does not need to learn and use a
multiplicity of programming languages and/or frameworks; Since he will
probably need to use a compiled language to develop the business logic
modules of the application for efficiency, security and integration into
non-web applications, there are obvious advantages in using the same
language and framework for the generation of the dynamic html.
-Because the module is compiled into native code or semi-compiled language,
there is none of the overhead of interpreting a script, and the security
risks associated with deploying the module to a web hosting server are
reduced because the compiled code will not be easily understood or modified
by third parties
-The design of the page layout is done using the flexible criteria and
methodologies that web designers are accustomed to working with, rather than
the more rigid criteria and methodologies that GUI application developers
are used to working with.
- Compiled languages like Object Pascal and C++, and semi-compiled languages
like .Net languages and Java are considerably more powerful than the
majority of scripting languages, and therefore give the developer access to
the full panoply of programming techniques and resources
- In the specific case of Delphi, the code is written in Object Pascal, a
high level language that yet to be bettered for clarity, reliability, and
programmer efficiency.
- The code if written properly may be compiled for both Windows and Linux
platforms

There are also some downsides if the dynamic web pages are to be deployed on
the server of a hosting service provider:

- Compiled modules could be regarded by the web hosting provider as posing a
security risk for its server since they could harm the system or make it
unstable; the risks are greatly mitigated,however, if the modules are in an
intermediate code and run by a .Net runtime, so that they effectively get
security checked on the server. This also makes them portable to any
platform for which a .Net runtime is available
- Hosting companies may not accept ISAPI modules because of their potential
to bring down the web server

Of course these disadvantages don't apply or are greatly reduced if the web
site is deployed on a dedicated server.

ASP.net seems to share many of the advantages listed above, so to my mind
is, together with its Java equivalent, worth considering as a higher level
framework having the potential to simplify the programming of server-side
event handlers and session management. The disadvantage of using it is that
it tends to make developers think that the web application may have the
same architecture as the equivalent desktop application. This approach
results in rather unresponsive applications, since all events are handled on
the server, even those that should more appropriately be handled on the
client.

Regards,

Enquiring Mind

Nicholas Brooks
Guest

Posted: Thu Mar 15, 2007 6:24 am Post subject: Re: Removal of Registry entries created by a Web App Debugge

Enquiring Mind,

Thanks for the detailed response. Gives me a chance to question my assumptions and decisions.

I've added my opinions below, but before I go on, I'll add this caveat: I'm definitely not questioning your choice of language/framework since I have no knowledge of your particular project needs.

Quote:

- There is a clear separation between static HTML and server-side code,
provided that the CGI/ISAPI code module confines itself to generating
dynamic content and plugging it into a static template .html file created by
a web designer using a tool like Dreamweaver, using for example the
TPageProducer class

Surely you could apply the same advantage to any of the MVC style web application framework's such as Rails or Django? The MVC pattern lends itself quite well to what you are describing. Perhaps Django is an even better example for what you are describing as it has its own template language for the view, thus the developer is forced to write the majority of the logic in the model/controller rather than the view.

Quote:

- The web application developer does not need to learn and use a
multiplicity of programming languages and/or frameworks; Since he will
probably need to use a compiled language to develop the business logic
modules of the application for efficiency, security and integration into
non-web applications, there are obvious advantages in using the same
language and framework for the generation of the dynamic html.

That is definitely one advantage, but then you may not be picking the best language (or framework) for the job of creating a web application. As with interop'ing with the business layer, you could always look at using a more interoperable communication method. Sure you may lose efficiency but gain in interoperability.

As with the web developer also writing the business layer, wouldn't you then look at having multiple developers, each having the skills specific to each problem domain (e.g. web developer, desktop app developer, etc.)?

Quote:

-Because the module is compiled into native code or semi-compiled language,
there is none of the overhead of interpreting a script

Yep agreed, though that may be less of an advantage as compilers become smarter and faster. Comes down to what is most important to your particular application. Program efficiency or programming efficiency, not that these two are necessarily mutually exclusive.

Quote:

.. and the security
risks associated with deploying the module to a web hosting server are
reduced because the compiled code will not be easily understood or modified
by third parties

Yep, but if you are seriously concerned with security and loss of IP then you'd probably look at hosting the app yourself, or have dedicated server hosting rather than shared hosting, and making sure your host'er follows best security practices.

Quote:

-The design of the page layout is done using the flexible criteria and
methodologies that web designers are accustomed to working with, rather than
the more rigid criteria and methodologies that GUI application developers
are used to working with.

I don't see why you could not have the same design flexibility with any of the other web application frameworks?

Quote:

- Compiled languages like Object Pascal and C++, and semi-compiled languages
like .Net languages and Java are considerably more powerful than the
majority of scripting languages, and therefore give the developer access to
the full panoply of programming techniques and resources

I'm not too sure what you are implying by 'more powerful' here, or programming techniques or resources.

But, comparing Ruby and Object Pascal, two languages I know fairly well, I'd say I can do almost everything in Ruby that I can do in Object Pascal. The things I cannot do or cannot do as well, are mostly just a tools/api problem than a problem with the language itself. But that is not to say I'd choose Ruby to develop my next desktop application that was going to integrate with MS Excel for example. Sure I could do it in Ruby, but it would be much easier to do it in Delphi for Win32.

Quote:

- In the specific case of Delphi, the code is written in Object Pascal, a
high level language that yet to be bettered for clarity, reliability, and
programmer efficiency.

Ok, but that is more of a subjective opinion. I love Object Pascal, but I've actually found Ruby to fit me better, and thus I'm more productive in Ruby compared to Object Pascal.

Quote:

- The code if written properly may be compiled for both Windows and Linux
platforms

Same goes for dynamic languages (i.e. multi-platform), but you don't have to worry about the compile step until runtime.

Quote:

There are also some downsides if the dynamic web pages are to be deployed on
the server of a hosting service provider:

- Compiled modules could be regarded by the web hosting provider as posing a
security risk for its server since they could harm the system or make it
unstable; the risks are greatly mitigated,however, if the modules are in an
intermediate code and run by a .Net runtime, so that they effectively get
security checked on the server. This also makes them portable to any
platform for which a .Net runtime is available
- Hosting companies may not accept ISAPI modules because of their potential
to bring down the web server

I'd be surprised if that was the case now especially if they are running IIS 6. Check out Application Pools in IIS 6 for more info.

Cheers
Nicholas

Enquiring Mind
Guest

Posted: Thu Mar 15, 2007 9:03 pm Post subject: Re: Removal of Registry entries created by a Web App Debugge

"Nicholas Brooks" <nbrooks (AT) infobase (DOT) com.au> wrote in message
news:45f8a148$1 (AT) newsgroups (DOT) borland.com...

Quote:

I've added my opinions below, but before I go on, I'll add this caveat:
I'm definitely not questioning your choice of language/framework since I
have no knowledge of your particular project needs.

Thanks for sharing your detailed comments. They demonstrate far greater

experience and knowledge of the available technologies than I have. Maybe
when you said that that you hadn't had time to move on from Web Broker
applications, you were just underselling yourself!

Quote:

Surely you could apply the same advantage to any of the MVC style web
application framework's such as Rails or Django? The MVC pattern lends
itself quite well to what you are describing. Perhaps Django is an even
better example for what you are describing as it has its own template
language for the view, thus the developer is forced to write the majority
of the logic in the model/controller rather than the view.

I know very little about these options, but as an incentive to learn more
about them, what sort of productivity gain do you reckon you achieve by
using them over using Delphi Win32 or ASP.Net tools?

Quote:

Although I have very little knowledge of the the various scripting languages
in common use except for VBScript and JavaScript, because I choose to stick
to Object Pascal and Visual Basic.Net (and would be prepared to make the
effort to get up to speed with C# one day), I get the impression that where
they may have the edge over these compiled languages is in the string
handling facilities built into the core language. However because the
compiled languages are fully extensible thanks to the extensive libraries
that they come with, that does not seem to be a big enough incentive for
using the scripting languages.

Quote:

As with the web developer also writing the business layer, wouldn't you
then look at having multiple developers, each having the skills specific
to each problem domain (e.g. web developer, desktop app developer, etc.)?

Certainly, but there is a lot to be said for standardisation so that any

developer can have a rough understanding of any application, especially in
smaller organisations. Also when there's a relatively tight degree of
coupling between two interacting applications, it helps if a single
individual can understand the architecture and logic of both.

Quote:

Yep agreed, though that may be less of an advantage as compilers become
smarter and faster. Comes down to what is most important to your
particular application. Program efficiency or programming efficiency, not
that these two are necessarily mutually exclusive.

I have done a fair amount of programming using compiled languages like
Pascal and Fortran, and a fair amount of programming using interpreted Excel
VBA. You know, I haven't found that VBA gives me much of a productictivity
gain because it's interpreted. What matters is the efficiency of the
compiler/interpreter at identifying errors, the power of debugging tools
like watches, and the speed of the code/test cycle. I find that what hits
productivity most is not the programming language per se, but deficiencies
in the documentation for the language and the object models and libraries it
uses, and in the usability of the IDE.

Quote:

I don't see why you could not have the same design flexibility with any of
the other web application frameworks?

The point I was making is that if you transfer too much of the page layout
work from the web designer to the web programmer, because the framework
encourages that approach, then the web pages may lose some of the
flexibility that the HTML was designed to give.

Quote:

I'm not too sure what you are implying by 'more powerful' here, or
programming techniques or resources.

I guess power means the ability to use all the features built into a modern

programming language like Object Pascal or C#. Many scripting languages only
provide a subset of these features, because of their more modest field of
application .

Quote:

But, comparing Ruby and Object Pascal, two languages I know fairly well,
I'd say I can do almost everything in Ruby that I can do in Object Pascal.
The things I cannot do or cannot do as well, are mostly just a tools/api
problem than a problem with the language itself. But that is not to say
I'd choose Ruby to develop my next desktop application that was going to
integrate with MS Excel for example. Sure I could do it in Ruby, but it
would be much easier to do it in Delphi for Win32.

At the end of the day, any programming language is just a formalism for

expressing data structures, logic and algorithms. What differentiates them
is how general, consistent, and readable the formalism is, and to what
extent the language design can help in avoiding or tracing logical errors. I
have noticed that in most academic publications, any pseudocode used to
describe an algorithm bears an uncanny resemblance to Pascal!

Quote:

I'd be surprised if that was the case now especially if they are running
IIS 6. Check out Application Pools in IIS 6 for more info.

Many thanks for the pointer.

Regards,

Enquiring Mind

Nicholas Brooks
Guest

Posted: Fri Mar 16, 2007 8:11 am Post subject: Re: Removal of Registry entries created by a Web App Debugge

Enquiring Mind wrote:

Quote:

Thanks for sharing your detailed comments. They demonstrate far greater
experience and knowledge of the available technologies than I have. Maybe
when you said that that you hadn't had time to move on from Web Broker
applications, you were just underselling yourself!

Geez, you make me blush! ;)

I've moved on from Web Broker for my personal projects (to Ruby on Rails) but our company still hasn't decided on the best approach to take. Also Delphi for PHP threw a spanner in the works, fortunately at the right time as Java was looking like a 'good' candidate. <shudder>

Quote:

I know very little about these options, but as an incentive to learn more
about them, what sort of productivity gain do you reckon you achieve by
using them over using Delphi Win32 or ASP.Net tools?

Oh, this could get me shot down in flames very quickly! As with every question like this, it all depends ;)

Why do I find it more productive:
- Built in support for deploying your application (e.g. capistrano)
- Built in support for unit testing
- taking convention over configuration (e.g. assuming table names based on Model names, Assuming primary key is named 'id')
- Handling the routing of the application for me. E.g. requesting /app/orders/view the app knows to call view method in the Orders controller.
- Validation built into the app. I just have to specify the rules in the Model. e.g. validates_length_of :password, :minimum => 6
- I love this: Dynamic find methods. I want to get all of the Customers where the their first name starts with 'Joe'. Orders.find_by_first_name('Joe'). This gives me back a collection of all of the customers with 'Joe'. And the really cool thing about this is that the 'find_all_by_first_name' method doesn't actually exist (read up on method_missing in Ruby).
- Ruby. Probably the most important reason for me. As I said before Ruby really fits me well.

Ok, I'll take my fanboy hat off now ;)

Problems I have with RoR:
- Harder to get it to work with a legacy database, and that is if your database is supported.
- Harder to get it to work in a Windows only environment (i.e. IIS), though this is slowly improving.
- No really good IDE like Delphi for Ruby or RoR. Hopefully CodeGear can sort this out soon.
- Performance isn't as good as our Web Broker apps, as in handling requests per second.
- If your approach and requirements don't fit in with the RoR way, it can be quite difficult, though not impossible, to write your application. Horses for courses and all that.

I suppose the best way to get familiar with what these frameworks can do for you is to start watching some of the screencasts, or doing some of the tutorials.

- http://www.rubyonrails.org/screencasts
- Unfortunately django doesn't have too many screencasts, so the best thing would be to read their website for info: http://www.djangoproject.com/

So, it depends as I said before. However, I'd recommend anyone planning on doing web development to check out these frameworks. Even if you don't end up using them, I'm sure you'll find some really cool ideas to help your productivity and introduce into your development.

Quote:

I think comparing VBScript and JavaScript with languages such as Ruby, Python and Perl really do these languages injustice. They are full-blown languages in every sense of the word(s). Take a look at IronPython for the .NET framework. It is an implementation of the Python language on .NET.

I'd like to revisit this part in a years time, as I think the landscape will have changed or be changing significantly due to these types of languages. Actually, have a look at Orcas and the language additions added to C#. These changes were brought about by features in languages such as Ruby and Python.

Maybe its a good idea if you have a look at one of these languages to add to your repertoire. I've noticed that I'm writing a lot of utilities I need in Ruby. I even wrote our backup system in Ruby, because it was easier for me to do so, plus it's cross-platform compatible.

Quote:

Agreed. We could argue the benefits between compiled and interpreted languages till the cows come home. As with all polarising issues, it has already been argued to death.

Quote:

Yes, but in an MVC approach, the framework doesn't encourage that. The View part is just that, a view of the data. So the logic found in the view is sparse, thus wouldn't get in the way of the designer. Secondly, with most of these frameworks, they encourage you to have templates that are then used by the individual pages. It is the templates that the designers are mostly interested in, and these templates don't contain or contain very little logic.

Cheers
Nicholas

Display posts from previous:

	BorlandTalk.com Forum Index -> Delphi Internet Isapi-WebBroker	All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum