5/16/2024 8:43:35 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss the use of the SalesLogix Web Platform, Client and Customer Portals, and the Application Architect (For version 7.2 and higher only). View the code of conduct for posting guidelines.
|
|
|
|
Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 13 Sep 07 11:52 AM
|
Has anyone had any success with this?  I spend so much of my time saving, rebuilding, deploying and sometimes restarting IIS for each change, then clicking through until something breaks, it'd be really nice to be able to set a break point. Not to mention aggravation having better code navigation and intellisense capabilities than the Application Architect would save me.
The instructions I received were to to create a new Project Workspace and check the box to export files as they are created. Unfortunately all this seems to do is dump XML and resource files from the Model, no .csproj, .cs, .ascx, .aspx, or .asmx files. None of it is very helpful. 
It looks like this is the right mechanism, because it has options to import projects and update with local changes, but the export doesn't seem to do the job.
Thanks
Eric |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 13 Sep 07 12:04 PM
|
Hi Eric,
In Visual Studio, go to file, open web site, and browse to the slxclient virtual directory where your website resides - then click the play button to debug - now you can set break points and step through your code
Nick |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 19 Sep 07 8:31 AM
|
 I feel a bit sheepish. Of course this works for debugging. If you are developing locally you are all set. I've been deploying to a remote web server, so I had to install the SLX web client stuff and deploy locally (I didn't want to fight with the security settings or my network admin). Thanks, Nick. This will save me untold hours.
Anyone have any suggestions for the development processes? Right now, I make the changes and test in Visual Studio. Next, I jump back to Application Architect and copy and paste my changes. While I'm there, I make my changes to the Entity Model, changes to the Portal Manager, etc. It works, but man does it feel clunky.
Thanks again,
Eric |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 19 Sep 07 8:38 AM
|
Yes it is very clunky, I hope the plan is to have App Architect (AA) as good as visual studio (I HOPE  ). I dont think it will be possible any other way as you need to get those changes/code additions/new properties into the VirtualFileSystem table in SLX - which is what happens when you develop in the AA....I cant see how else you can do that without at least finalising your code changes in AA... |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 19 Sep 07 12:56 PM
|
It is an easy process to develop your own assemblies to plug in as business rules, event handlers, etc. These you will develop in VS as you would any assembly. Going this route makes it easy to develop your own libraries of code to reuse as needed for any business rule, event handler, action, etc. Not only that, but you'll have all the tools, such as refactoring etc, available in VS for you.
For developing SmartParts, there's a line you have to keep in mind. IMO, developing a SmartPart in VS, just to develop it in VS makes little sense when you could throw a simple one together so much faster in AA. However, for a more complex QuickForm, it is easy enough to do in VS. You just need to create a project, add your ASCX file and, if you need to be data bound, inherit from "Sage.Platform.WebPortal.SmartParts.EntityBoundSmartPartInfoProvider". You'll need to wire up any bound controls (which don't have to be SLX controls) by overriding OnAddEntityBindings with code like:
this.BindingSource.Bindings.Add(new Sage.Platform.WebPortal.Binding.WebEntityBinding("EntityPropertyName", ControlName, "ControlProperty"));
// continue with binding other controls...
Then you'll have access to the same things you have in QuickForms, such as getting the current entity object (you'll have your BindingSource from from your base class of EntityBoundSmartPartInfoProvider):
Sage.Interfaces.Entity.IMyEntity myentity = this.BindingSource.Current s Sage.Interfaces.Entity.IMyEntity;
When you're done with it, you'll add it to the SmartParts section of the portal's Support Files, then add it to a page as needed.
Make sense? |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 20 Sep 07 11:19 AM
|
Nick, I could not imagine that AA will ever be at a level of VS. Its just not where Sage makes their money. However the community can enhance AA where it makes sense to add new functionality that makes it easier to develop with.
Mark |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 20 Sep 07 2:30 PM
|
Shall we begin a features list?
Personally, I'd see it more likely as a VS plug-in than a series of enhancements to AA, so I'll list essential features from that perspective...
* Project Workspaces - Strictly speaking, does this do anything Configuration Manager doesn't?
* Bundle Model - This should be fairly straight forward to implement, it's just zipped XML, but the UI might be tricky
* Entity Model - and ...
* Portal Manager - The Entity Model and Portal Manager seem like the most complex. Having not written a VS plug-in myself, can we just reference the DLLs and use them as-is, adding them to the View menu in VS?
* VFS Explorer - This could be treated as a Source Control provider
|
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 21 Sep 07 7:25 AM
|
Originally posted by Eric J. Van Winkle
Shall we begin a features list?
Personally, I'd see it more likely as a VS plug-in than a series of enhancements to AA, so I'll list essential features from that perspective...
* Project Workspaces - Strictly speaking, does this do anything Configuration Manager doesn't?
* Bundle Model - This should be fairly straight forward to implement, it's just zipped XML, but the UI might be tricky
* Entity Model - and ...
* Portal Manager - The Entity Model and Portal Manager seem like the most complex. Having not written a VS plug-in myself, can we just reference the DLLs and use them as-is, adding them to the View menu in VS?
* VFS Explorer - This could be treated as a Source Control provider
|
|
A VS "plugin is NOT the direction Sage is going in.. The idea of a VS plugin was discussed a few years ago when dotNet technology was being discussed but was dropped..
The BIG reason.. Having a system that does not depend on 3rd party tools to do the typical customization that is done in most projects.
This is what the partner community wanted .. and got.. Now it is based on popular technologies and can be enhanced significantly using VS.. but it's not a requirement.
Why place your dependency on a 3rd party?
110% behind the approach taken..
--
rjl |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 21 Sep 07 7:29 AM
|
FYI.. there are "wizards" that will be part of SP1 that will make it VERY easy to build out the basics.. as they say.. justa few "clicks" and you are there!
Over time more and more wizards will appear to make things a lot easier.. but you will still be able to get into the "guts" and do whatever you want.
The best of both worlds.
--
rjl |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 21 Sep 07 8:05 AM
|
Hey Eric,
So the quest here is to extend VS to support 7.2 development. From a product standpoint it makes sense for what Sage is doing by owning the IDE. Because of (1) the demographic of the customizers, and (2) direction of integration that the team is going with Web, Wireless and Mobile in the future it makes most sense to own the shell and continue to evolve it. As you are aware this is really a 1.0 release of the shell and has some way to go. The power in the future is not only what the internal team does with it feature wise, but also what we as a BP partner community do with it. AA is based on CAB (Composite UI Blocks) and is extendable outside of what Sage is doing. It is quite possible to add the features you will need in the future to make it easier to develop those customer solutions. Now back to point 1, really there is a mixed bag of capabilities in the SLX business partner community and at times the Bar is very high in VS. A large portion IMHO are working on learning C# now and will take some time to get up to speed, add to that new ways of doing things such as Generics, Dependency Injection, workspaces, then add on web controls (ASCX) and the curve gets quite large. By having a simplified AA, as it matures, will allow the team to bootstrap that process and try to reduce the amount of technology casulities and invest in Sage wholey owned properties .
Make Sense?
Just my thoughts
Mark
|
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 21 Sep 07 12:45 PM
|
It makes sense, it just doesn't really fit the paradigm I'm familiar with.
I've been a .Net developer for almost 5 years now and am new to SLX, and as much as AA looks like VS, it isn't anywhere near as feature-rich or user-friendly. Granted, AA isn't meant to compete with the breadth of VS features, it's strictly targeted at a specific type of project on a specific platform. Still, I had hoped we might see a VS plug-in to give developers access to the many useful tools VS provides. So, instead of what a VS plug-in would need, here is what I see AA lacking:
* Debugging - I can do this by opening the site in VS and that has gone a long way, but why can't I set a breakpoint in the code in AA?
* Object Browser - In the absence of real extensive documentation, this would be handy.
* Intellisense - AA does something, but not nearly as much as VS Intellisense provides
* Design View - User Controls can be designed in Source, Design, and Code views. Custom Smart Parts designed in AA are limited to Source view until you compile and deploy. The Quick Forms have a Design view, but it's so limited in layout control. Maybe this is a result of the requirements to support the write-once-run-in-network-or-web-client promise, but if so, it's to the detriment of the web client.
My two cents, devalued with the falling US dollar,
Eric |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 23 Sep 07 8:08 AM
|
Hey Eric,
lets not bring in the US dollar. Ouch.
lets see what we can tackle here. Debugging.. Not really what I would want to get into right now with AA. Object Browser, hum.... not a bad Idea. Something maybe the community wants to pick up on. Since we have reflection, html browser and can discover the assembiles in the underlying directory (Used in the code editor for Intelli ...) it is quite doable. Intellisense, I think and Ryan can confirm the reason that intellisense is not quite and probably will not be is the way MS tackles is vs Sage. MS has a more active Intellisense engine that works not only off of the reflected assemblies but als creates doc.xml files for each of its assemblies. The source code editor embedded in AA works off of refection. Design view ... that is also an interesting one, there is indeed a form of designview in the quickforms but leaves much to the imagination. First what are the control types from a 100 ft view. When I look at the view I would like to see some semblence of the end view. Picklists, lookups, email edits, grids looking like their runtime counterparts. I am sure that will be comming at somepoint. Custom Smartparts are a little different, however it could be possible to scrape the smartpart, background compile it and use the meta/reflected data to show what it would look like. It is also possible to rehost the asp.net runtime in a local process and render it that way for display as well.
Some thoughts
Mark |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 24 Sep 07 3:14 AM
|
| I think the best point of all made here would be the ability to have code/design view for the smartparts (custom and quickforms). I find the c# snippet approach rather confusing and limiting, and getting javascript into the page is tricky as the events dont fire as you would imagine (mainly because the invoking of a smartpart does not cause a load event on the browser. If this was available I would be happy to code entirely in AA - and just use VS to debug should I require. |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 24 Sep 07 6:54 AM
|
As I rethink my earlier post. Creating an object browser may not make as much sense at all. I look at my workflow and I believe that Ryan is pretty close, but for object browsing I use Reflector. Why, just because it is such a great tool, not only does it give me the types, members, events and everything else, but it als decompiles the code in a readable form. Having the code available at that level is just great, as it usually can give the intent, and show what is requred/not. The tool is free and the time to replicate this functionality just does not make sense. If anything a browse with reflector menu item would be nice, with some settings to the reflector install.
I have to agree with the smartpart design/code views and definately the JavaScript development/debugging. However this is a big development effort and it is only in VS2008 that MS is finally adding native Javascript support into the product (previous versions munged up code, did not have great javascript support like intellisense (added in 2008)). Nick, have you downloaded Beta2 of VS and tried to develop your smartparts with it. I know it is not integrated and the like but the tooling is so much richer and the VS team is soooo much larger then the whole Sage SalesLogix team (600 ppl for VS if I rember rightly) you are just not going to get that integrated in the near future.
Mark |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 24 Sep 07 6:59 AM
|
Eric,
You say you have 5 years of VS.. and are new to Saleslogix...
Well.. there are many of us in the Partner community that have over 7 years experience on SalesLogix and I have a lot of close associates that were there from day 1 (Just a little over 10 years_.. Some go back top the early days of ACT (the "father" of SalesLogix) and that's been around for 20 years. We've used VB, etc.. as well as VS when those technologies "emerged" to work with SalesLogix.
It's very useful to get an understanding of the roots and rich history of SalesLogix which was designed by a person who was a pioneer in the "CRM" business - Pat Sullivan (someone who would debate w/you over the value of American dollar 
The release of v7.2 web is a major technological breakthrough.. and I'll bet the "competition" wished they had such a platform to build on (but that's for another discussion).
If you've never taken a SalesLogix formal training course (and I'm not talking about one by a Partner.. but by SalesLogix), you should take the v7.2 web Engineer and v7.2 web developer's course... it will be a pleasant surprise. v7.2 was not meant to be something that one learns on their own but something that one needs formal classroom training on. In fact, the ONLY way ANY Partner can get v7.2 web developer certification is to attend a formal Sage SalesLogix class.
Oh yes, your VS experience will be a great asset.. but not required
--
rjl
v7.2 SLXWE/SLXWD
v6.x and v7.x certified SLXE, SLXD & SLXWE
Dynalink Certified SLXDYN
TaskCentre Certified |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 24 Sep 07 9:48 AM
|
Bob,
Yeah, I appreciate that I'm coming at this from a different perspective from most SLX professionals. I've discussed the classroom training from SAGE with management, and I've no doubt that will be part of my professional development. I guess my frustration is that we are trying to do several things that this release isn't intended to do (using Sales Processes to launch web forms, for example) and while the architecture seems to support our efforts, both the tools and the documentation to facilitate the same immature at best.
I love Reflector. It's a great tool. I used it to begin my own documentation of relevant parts of the SalesLogix object model before we started development. The problem is, it's not part of an integrated tool set. I can use Reflector to examine the object model. I can use Visual Studio to launch the site and set my breakpoints to debug. I can use Nikhil's Web Development Helper for all of my client-side debugging. (If you are developing on your local machine and you do not have this tool installed, get it now. Do not pass go. Run, don't walk. Use it for JavaScript and ASP.Net debugging, HTTP header and state information from a sidebar in IE. Thank you, thank you, thank you, Nikhil. http://projects.nikhilk.net/Projects/WebDevHelper.aspx ) But then I've got to go back into AA to commit my changes, and I guess I'm just spoiled by VS.
* The interface is less than intuitive. Shouldn't double-clicking open a file for editing? What's with the "right-click then open"?
* The design view for Smart Parts that does exist in AA is woefully inadequate. The table based layout is an enormous pain.
* The Virtual File System Explorer could use some work. If I make a change there, shouldn't there be a real easy way to say "Keep My Changes" or "Do Not Update With Code Generation"?
I guess while I'm at it, I should mention that I also expect better work flow, source control or change management, a much more "lickable" skin for the Web Client itself, regular in office massage, [Insert Political Policy Goal Here], developer documentation, and a pony. Maybe the skins are negotiable...
I'm sure the rational is that 80% of what users need should be ready out of the box. 80% of the remaining business specific requirements should be addressed by configuration using the Admin tools and AA. My problem is that some mission critical functionality falls into that untouched 4% and I just want to be able to easily use a tool set more appropriate to that kind of specialized customization.
I'll try to be patient and maybe some of my wishes will be granted. I just won't start picking names for that pony, yet.
Thanks,
Eric |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 25 Sep 07 6:34 AM
|
Great points Eric.
As they say.. on has to walk before running and certainly the present state of AA id the "walking" state (although it sometimes feels like a very fast walk).
A few of us have had the privilege of having access to the technology that is in the new web (AA) for "some time". We've seen this go from a VERY crude demonstration of technology and capability to what it is today in a very short time. Like any major Enterprise Application/Tool what is key is to have a solid foundation and THEN add the bells and whistles. SP1 will intro some of these add-ons with the introduction of "wizards" to assist in building basics.. and well we'll just have to wait for "movie at 1"
--
rjl |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 25 Sep 07 7:05 AM
|
Eric,
I have to agree with you with regards to being spoiled in VS. I feel the same and I am sure that there are many developers who love the flow and flexability that VS offers. Its hard to deny what a great tool it is for getting work done. Many of us have been in Hybrid mode for some time, developing in both SLX Architect/AA and VS and I personally spend more time in VS, developing SLX .Net Extensions rather then script code. RJ mentions the SP1 wizard enhancements, and I personally think they are great step forward for the masses but I like to see more advanced capabilities and definately workflow improve. There are alot of little nucenses that need to be addressed (AA context menus, simplification stuff). I would like to see a context menu on the Project Explorer that allows for deployment instead of having to open up and choose deploy active/Selected.
I know the team well and I am sure that they are working towards bringing the best out, and I expect as they start to build for the lan client more changes will come to ensure that process is supported well.
Mark |
|
|
|
Re: Using Visual Studio to Develop and Debug SLX 7.2 Web Client
Posted: 25 Sep 07 8:10 AM
|
Hmmm... I'm still not hearing a lot of support for my pony request.
I've heard some word about the wizards in SP1 and it is certainly encouraging. I should probably point out that I'm generally pleased with SalesLogix as a new developer to the platform. Like I said, even where this release doesn't support the functionality we are looking for, the architecture seems solid enough to build on. As much as I have fumed and beat my head against my desk working with RC1 through the Gold release, trying to build the functionality my company needs, the web client itself seems to perform as well as I'd expect for a 1.0 product. I just wish some of the non-standards based stuff were a bit more transparent ("Where in the database is the Smart Part ID associated with the Title I gave it in the Portal Manager?") and either SLX's tools were a bit further along, or there were an easier way to use other tools. If not a full plug-in of AA functionality for VS, just a VFS-Source Control plug-in or a utility to expose the VFS as a mapped drive to simplify working outside of AA would go a long way.
So, any other suggestions for methodology or tools? I'm putting together outlines for an article or two to submit once I complete my first customization end to end. I'm thinking of writing one How-to to walk through table to entity to quick forms to custom smart parts (I'm told the Magic Carpet example is out of date) and another describing how I'm adding the web forms capability to the Sales Processes. So far, here are the high points of the first:
Tools:
* Application Architect
* Administrator
* Visual Studio 2005
* Lutz's .NET Reflector
* Nikhil's Web Development Helper
General Steps:
1. Create Table in Administrator - DB Manager
2. Create new Package in Entity Model in Application Architect
3. Create new Entity in new Package in Application Architect
4. Create Relationships from Entity to parent entities (per advice from Sage Support)
5. Build Interfaces
6. Create Quick Forms for Entity
7. Add Quick Form as a Smart Part to a Page in Portal Manager
8. Build Web Platform and Deploy
9. Copy .ASCX generated for Quick Form and edit in Visual Studio
10. Add Existing File (edited version of ASCX) to VFS
11. Add "Smart Part (Custom)" (ASCX from above) to Page in Portal Manager
12. Open Web Site in Visual Studio and set Breakpoints as needed for debugging
This is just skeletal and doesn't include the stuff I'm working out now, like dealing with Insert Mode, etc., and I swear it's not intended as a 12 Step program for moving off of AA. (Some might argue that I need a 12 Step program to recover from my addiction to Intellisense. http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html ) I hope to flesh this out considerably as I understand what other users are doing and what their pain points are, where they differ from mine.
Thanks,
Eric |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|