Okay, time for me to poke my head out of here and into the general community. Since there is some concern about what we're doing I thought now would be a good time to share more with the community at large on what we are doing, and where we are planning on
going. As I'm sure anyone can imagine, we inherited this code and some rather large legacy issues which have to be dealt with right away. One of the main problems with any long term running DNN module that emcompassed DNN 1 through now, up to DNN 3 is it's
code cleaniness, as module standards and capabilities for all of us have changed so much in the last 18 months. DNN 3 has caused alot of "bad style" elements in modules to break hard. Elements such as
links no longer work under DNN 3, and a variety of other issues. We have done in excess of 5,000 code and ascx changes to Portal Store and are continuing to resolve any remaining issues as quickly as possible. We knew it was going to be a challenge, and
yes, we were right :) Our main immediate goals was to provide continuality between DNN 2 installations and the upcoming DNN 3 version. This, we felt was important for a variety of reasons - not everyone upgrades to the latest version of DNN right away. We
still feel those customers should have our latest code, and also a smooth module migration between one version and another. Thus the rationale for using BDPDT. If someone takes a look at Portal Store 6.5, they will first notice that there is no reference from
Portal Store to DotNetNuke. Any changes in DotNetNuke are transparent to Portal Store. Now - if you like to modify the source, and make Portal Store into something it isn't already - that's good news for you, because you don't have to worry about porting your
code in between versions of DNN. That work is done automatically for you. It also provides you continual version support and upgradability regardless of your DNN version. That choice is now up to you, not us, the module developer to dictate. As far as I know,
and I'd almost be willing to bet on it - we have the only code that can run on DNN 2.0, DNN 2.1 and DNN 3.0 installations without code changes, and that includes taking advantage of HTML Edit Providers in DNN 2.1 and DNN 3.0. Oh as far as localization? I'm
having fundamental issues with that right now with the way DNN is doing it. So we're waiting to see what DNN 3 RC has before deciding on whether or not to write localization code ourselves instead of using DNN 3's built in localization. This is phase I for
us. Our second phase, which has already slowly begun, is to split out the various business elements of portal store that is contained in the one module, into more finite business modules. Thus allowing for a more tailored look and feel and also greater control
over the overall layout and design of your store. At the same time, UI improvements will be performed to areas in which we feel are necessary, and our dynamic provider based technology that we use well in Email Manager will be utilized in Portal Store to provide
a better and more flexible suite of transactional processing options. Phase III - and the real reason we are doing Phase I and Phase II. This is where we want to be as quickly as possible, and we are devoting all our time to it, versus getting our website(s)
polished up and completed and other projects (btw - it is forming up slowly at dotnetnuke-modules.com). Evolutionally, we are integrating on our other suite modules to provide a complete end to end e-commerce, marketting and sales force solution. Combine the
richness of Email manager with Portal Store and add into it SiteTrack's distributed system monitoring capabilities, and when all the pieces of the puzzle work together - you will have complete and total capabilities for a complete end to end solution. --Richard
ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.
Do any of these DNN integrated store-front modules implement ebay integration library? This is different than just exporting an ebay-friendly loadfile via css ... Is anyone familiar with http://www.aspdotnetstorefront.com/ and would know how CataLook and AIS-EC
would compare feature-wise?
hi , i treid to add the online store of the catalook to the dotnetnuke 3.8 , and i tried to use the manual of quick guide insallation but it is too ambiguos and i dont have any advantage of it . so please if any one has an experience of the specific steps to
add the on line store reply me . thank you .
hello , can i ask you how can i add the PA-modules in the online store to the dotnetnuke 3.8 , so can i add it as module or as disconnected porject . thank you .
Well, I agree, the install.htm file was not of much help. However, I have successfully install it after a lot of efforts. I am still struggling with Payment part. I believe, the integration has issues. I am waiting for DNN 3.0.9 or RC, hopefully, it will work
better with it. :)
This is just a quick reply ... not comprehensive. I haven't seen the integration library anywhere yet; but Catalook has quite a few Export features, and one of them is export to EBay. I had a look at the features for http://www.aspdotnetstorefront.com/. It
looks quite comprehensive; above all, it looks like a mature solution. My gut feel was that right now, it is offering more features than the DNN solutions (I'm assuming of course, that everything advertised, works as smoothly as the advertising site does ;-)).
All the DNN solutions, with the exception maybe of Portalstore, are very new. I invest time in Catalook, not so much for what it is now, but for what I believe it might become. Right now, it's a neatly designed tool with a lot of flexibility, and everything
that is there, works. What's needed now is the many users, feedback, and spit and polish that makes a product truly good - the useful lookups, searches, and attention to usability; a wide variety of reports, ect. Another consideration is probably the nature
of your site. If you are primarily a shopping cart, you could go with a solution like the aspdotnetstorefront, and right now, that may be the best value for your money. I like that when I use a DNN cart, I get the DNN framework - and my shopping cart. So I
could drop the cart, a support forum, a blog, and some custom modules - activate warranty etc. on the site with very little ado, and I have all the other 'built-ins' like the sitelog, user management etc. available to me. And with the healthy competition I
see between the DNN carts, provided development continues at some of the pace we've seen in the last year, I think that within a year or so, the DNN solutions should have more than caught up with solutions like aspdotnetstorefront.
Richard, Do you have a time frame for the different phases of work? I currently have 6 sites I've developed locally (not published yet) which I'm stalling the clients until I there is more control on the layout of the store. I've invested too much into Portal
Store to give it away completely and am awaiting your Phase III developments to complete. Hopefully that would be in a reasonable time frame (for my clients sake). No pressure :-).
Let me just quickly chime in on Richards comments. Think about the evolution of DNN over the last 18 months. The move from DNN 2.1.2 to DNN 3.0 has been a huge undertaking by the core team. At tmes some might even think it was too big a leap, but either way,
this is where we are. what Richard has done by abstracting calls to DNN into his own interface between his modules and DNN is fantastic. This is the big headache for most module developers. Lately it seems that when DNN upgrades, Module developers have to
make changes to go along. In DNN 3.x this was taken to the extreme and as such we are seeing some modules that were freely developed and distributed being abandoned due to the overwhelming changes for some folks. Abstraction of the DNN calls allows for Richard's
modules to ride the wave between DNN versions. while the initial effort to migrate the modules to the BDPDT layer has taken a bit of time and inevitably cause some introduced bugs, the long term effect is quicker time to market for his customers as DNN moves
forward. Now correct me Richard if I am incorrect on any of this but it really is a great concept. Even I have waited to migrate my PowerReports Pro module line to DNN 3.x just because there are still too many unknowns and changes upon changes. Why spend the
time only to change it yet again I keep saying to myself. Heck, I'd like to get a look at Richard's BDPDT if it meant saving time long-term. I bet I'm not the only one. ;) So, I think all-in-all everyone and everything will settle in again for a period of
time. Modules will catch up. DNN 3.x patches will come out. DNN consultants will upgrade their clients. But hopefully we all have taken some good lessons learned from it all and end up with a bigger, better community and product in the end. My 2.5 cents worth.
;)
Samantconsulting: First priority is surviving DNN's beta program right now and remaining somewhat sane. At the same time, which is why some people are having alot of burps with us the past few weeks, is just simply how much code we're re-writing between each
"minor" non-versioned release of Portal Store. Between weeding through the code and figuring out what's still active code, what is no longer used, and re-tooling it to BDPDT and our coding methology - it's been a great month. To be fair, and I do have to stick
up for Snowcovered on this. ANYONE that has had a module survive from all the way back from ISPY days has significant amount of legacy issues if their module was anything on the complex side. Any code will show signs of stress given the amount of architecture
changes over the last two + years of in production use. We're fastracking alot right now, and really have to wait for alot to see what happens with DNN 3. *assuming* there isn't too many more changes - I think we've resolved all the underlying issues with
that tonight and now are cleaning up / fixing the remain issues with the other modules. Now I digress .. back to your timelines.. Skinning which sounds like your primary initial requirement will be out first. It's already split and being coded on right now.
It will be a generic module skinning engine in BDPDT, so all our products over time (if needed) will end up using it. Alot of our significant efforts that we're laying out now won't even be noticable to the average user unless you start poking around in the
code, as elements move to "engines" under BDPDT from being part of a singular module suite. Yes, I do get tired of writing similar code for different modules more than once :) Brian: There was no data changes to 6.5, only stored procedures to support DNN 2
/ 3 out of the same SQL code - now there was a trick ;) The majority of the changes were in the source code itself, moving it to support both DNN 2 and 3, and simpifying the code by using BDPDT standard control, settings, default handling functions. The only
thing that I think MAY be impacted upon a move up from DNN 2 -> 3 with Portal Store might be your stored image locations. But we might backdoor a change to that if it turns out to be an issue. Totally different handling of image paths, relative directories,
etc from DNN 2 and 3. Lucast: BDPDT has been our lifesaver. DNN is changing too rapidly to support large modules. Having to halt development and re-tool once a year is a costly endeavour. Email Manager alone would bury us if I had to do that every year. A
good example. Moving Portal Store probably consumed about 60 person days of effort in total so far. Email Manager which was already abstracted out of DNN. 2 days. # of lines of code in each? about the same. BDPDT isn't open source (I hear the gasps already)
for some very specific reasons. It locks down our commerical controls that we are bundling in with our apps. We could not continue to provide source code for our modules that we do, and expand their functionality with commerically available controls otherwise.
It will also start to control our licensing and deployment of modules to client sites - not exactly source we want floating around out there. We've thought about releasing BDPDT as a product for developers, but that would mean I'd have to document it. Egads.
Free copies of modules for documentation volunteers :-) Now I have to get out of here and get back to re-writing more code into non-friendly url formats, I know I still have more of them to do in some app or another...and buy another 1GB of memory for my now
swapping workstation. --Richard
ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.
Richard Cox
Participant
1635 Points
327 Posts
Re: Stores
Jan 21, 2005 04:30 AM|LINK
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.
pmgerholdt
Participant
1237 Points
248 Posts
Re: Stores
Jan 21, 2005 05:26 PM|LINK
haythamsaira...
Member
10 Points
2 Posts
Re: Stores
Jan 24, 2005 10:00 AM|LINK
haythamsaira...
Member
10 Points
2 Posts
Re: Stores
Jan 24, 2005 11:39 AM|LINK
IndianGuru
Contributor
5392 Points
1093 Posts
Re: Stores
Jan 24, 2005 11:43 AM|LINK
tinky_lou
Member
725 Points
145 Posts
Re: Stores
Jan 24, 2005 12:53 PM|LINK
samantconsul...
Member
70 Points
14 Posts
Re: Stores
Jan 27, 2005 04:38 AM|LINK
brian_c
Star
11292 Points
2259 Posts
Re: Stores
Jan 27, 2005 05:52 AM|LINK
lucast
Contributor
4805 Points
961 Posts
Re: Stores
Jan 27, 2005 05:53 AM|LINK
Richard Cox
Participant
1635 Points
327 Posts
Re: Stores
Jan 27, 2005 06:29 AM|LINK
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.