|
Home > Archive > Commerce Server General > August 2006 > Custom Pipeline - Config File
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Custom Pipeline - Config File
|
|
|
| We are writing a custom pipeline component for CS 2007 using C#. Do custom
pipeline components have access to a tradition .NET .config file or similar?
Thanks.
Mark
| |
| Ravi Shankar 2006-08-18, 1:25 pm |
| Hi Mark,
To make a custom pipeline component configurable explore the
IPipelineComponentUI Interface. This will permit you to enter some
configurtion data after the component has ben inserted into the pipeline
through the Pipeline Editor.
--
Ravi Shankar
"Mark" wrote:
> We are writing a custom pipeline component for CS 2007 using C#. Do custom
> pipeline components have access to a tradition .NET .config file or similar?
>
> Thanks.
>
> Mark
>
>
>
| |
|
| Thanks Ravi. Just for grins I tried out getting AppSettings from our web
site's web.config file using the code below. It worked. Any reason for
avoiding using the .config file for consistency with the rest of our site?
While configuring via the interface you mentioned below might be relatively
straightforward, the consistency of having everything in the web.config
seems quite appetizing? Thanks again.
string test = ConfigurationSettings.AppSettings["foobar"].ToString();
Mark
"Ravi Shankar" <shankycheil@newsgroup.nospam> wrote in message
news:080E081A-C50C-4D76-9471-5C92636E9741@microsoft.com...[vbcol=seagreen]
> Hi Mark,
>
> To make a custom pipeline component configurable explore the
> IPipelineComponentUI Interface. This will permit you to enter some
> configurtion data after the component has ben inserted into the pipeline
> through the Pipeline Editor.
> --
> Ravi Shankar
>
>
> "Mark" wrote:
>
| |
| Ravi Shankar 2006-08-22, 7:24 am |
| Hi Mark,
Nope, none at all.
In our case, we needed to build custom modules within CS for functionality
such as loyalty points etc so from a design standpoint we split it at 3
levels. One was the CommerceModule that loaded along with other modules and
created an instance of the funcitonal class. The second set were the pipeline
components that access the class instantiated in the module to perform other
actions on the orderform object. And the final part was the user controls to
address the UI functionality from the site.
Some of the benefits we got were
1. Our custom resource (tables an all) were easily transportable to the
target system using the PUP/UnPUP mechanism
2. The connections strings were built during deployment (so we did not have
to do any post-deployment code edits (inclusing web.config))
3. In case of a hihg-load scenario, I could move just my resource to a
totally different SQL Server by using the Commerce Server Manager & SQL
Enterprise Manager (no edits required)
4. Since we used a intermediate business functionality, the combination
could be deployed across multiple teirs without impacting the base CS
architecture.
5. If another customer like my custom resource, I could package and ship it
across to them for their developer to integrate it  ))))
In your case you'd necessarily need to edit the web.config file post
unpackaging to make the changes for the deployment system.
--
Ravi Shankar
"Mark" wrote:
> Thanks Ravi. Just for grins I tried out getting AppSettings from our web
> site's web.config file using the code below. It worked. Any reason for
> avoiding using the .config file for consistency with the rest of our site?
> While configuring via the interface you mentioned below might be relatively
> straightforward, the consistency of having everything in the web.config
> seems quite appetizing? Thanks again.
>
> string test = ConfigurationSettings.AppSettings["foobar"].ToString();
>
> Mark
>
> "Ravi Shankar" <shankycheil@newsgroup.nospam> wrote in message
> news:080E081A-C50C-4D76-9471-5C92636E9741@microsoft.com...
>
>
>
|
|
|
|
|