StrataFrame Forum » Updates and Information » StrataFrame Users Contributed Samples » Code Snippet Editor

Code Snippet Editor

Charles R Hankey — Fri, 14 Mar 2008 13:33:59 GMT

This may fall into the category of "Well, duh!" but just in case anybody is lower on the learning curve than I am :

There is an extremely cool code snippets editor on the tools menu of VS. Basically is adds stuff to intellisense.

I created a new folder for Strataframe snippets. Here is an example of a Custom Field Property snippet

( this is instead of cutting and pasting from the bo.designer generated code as in the beginner tutorial. Note that the string datatype is hardcoded so either make a $replacement$ for it or remember to change it if your custom field prop isn't string )

#Region " Custom Field Properties "

''' <summary>

''' $Custom Field Description$

''' </summary>

''' <remarks></remarks>

<Browsable(False), _

BusinessFieldDisplayInEditor(), _

Description("$Custom Field Description$"), _

DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _

Public ReadOnly Property [$Property Name$]() As System.String

Get

Return $Property Value$

End Get

End Property

Protected Overrides Function GetCustomBindablePropertyDescriptors() As MicroFour.StrataFrame.Business.FieldPropertyDescriptor()

'-- Create and return a new array of FieldPropertyDescriptor

' objects that contains the ReflectionPropertyDescriptor

' for the $Property Name$ field.

Return New MicroFour.StrataFrame.Business.FieldPropertyDescriptor() { _

New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _

"$Property Name$", GetType($BOName$))}

End Function

#End Region

On the Imports tab you enter the stuff that must be imported for this to work

System.ComponentModel

Microfour.Strataframe.UI.Windows.Forms

For a shorcut I used cpr

Now if you are in the BO code, you just but the cursor under the Event Handlers region, type cpr, hit tab and everthing you see above gets typed in with the cursor on the first Replacement. You fill it in, tab to the next one etc.

If the imports statements are not at the top of the declaration, the snippet editor puts them in !

I think this is cool and I'm pretty sure I've only scratched the surface of the possiblities here.

You may not see the Code Snippet Editor on the Tools menu ( for some reason mine didn't have it ) but if you Google you'll find it for download with easy instructions to install in. Comes with a lot of predone VB stuff as well.

I've added

FillbyParam ( fbp )

Public Sub Fillby$Subname$(ByVal $param1$ As String)

'-- Establish locals

Dim loCommand As New SqlCommand()

'-- Build the query

loCommand.CommandText = "SELECT $Fieldlist$ FROM $tablename$ WHERE $param1$ like @$param1$+'%'"

'-- Add the parameter

loCommand.Parameters.Add("@$param1$", SqlDbType.NVarChar)

loCommand.Parameters("@$param1$").Value = $param1$

'-- Execute the command to fill the business object

Me.FillDataTable(loCommand)

End Sub Fillby$Subname$

MessageboxYesNo '

Dim dr As DialogResult = _

MessageBox.Show("$Message$","$Heading$", MessageBoxButtons.YesNo, MessageBoxIcon.Warning)

If dr = Windows.Forms.DialogResult.Yes Then

End if

( sorry for the blank lines but I can't figure out how to turn off big line spaces after pasting code )

Would like to see what you guys who know a lot more about this stuff are doing with snippets :D

Charles

RE: Code Snippet Editor

Trent L. Taylor — Fri, 14 Mar 2008 13:33:59 GMT

[quote]My most pressing concern has to do with the thought that setting these properties at the BO level can lead to the need to repeat the process for any "new" BOs that are created for the same table.[/quote]

This is the first problem...you should not be reproducing the same code again anyway! A business object represents an entity such as a table or view in a database. You should have ONE primary BO that represents this entity. Then if you have a scenario, such as a report, that will extend this business object, then you will create another BO and inherit off of the primary business object. So it will inherit the logic of the parent.

[quote]Is that the case, or does the "*designer" file hold this metadata and therefore can be reused for other BOs that need it?
[/quote]

You NEVER change the designer file as anything you change in this class will be overwritten when you rebuild through the BO Mapper. Add all of your custom code in the MyBo.vb or MyBo.cs file. This is the beauty of partial classes, you can have a single class declaration spread accoss multiple physical files. The way you use this logic on another BO is by inheriting this BO class on the other BO.

[quote]Also, (and this may reflect my ignorance of SF), VFE has a data layer that allows for PEMs at the column, cursor and DataEnvironment levels. Is there something similar in Strataframe?
[/quote]

There are ways to do this, but you will first have to change the way that you current are used to working with data. Most VFP developers (including ourselves) have a hard time learning to deal with disconnected data. Depending on what you are trying to accomplish you may want to do some of this at the BO level by handling the field changed events or one of the many other events of the BO. You can add handler events at the column level or intercept an event anytime ANY field is changed (or accessed). You can see how to add this type of logic in the help docs under the Application Framework -> Business Layer -> Business Object Mapper -> Dynamic Business Object Events.

Secondly, here, some of this may be done at the database level, again depending on what you are trying to accomplish. SQL Server is far superior to VFP databases and tables in every aspect (and this is coming from a once die-hard VFP guy :) ) but requires a change in thinking. There are triggers and cascades just like in VFP that can be handled here as well.

You should not be adding custom code at the DAL. You can however handle events that affect what the DAL actually does, but the DAL is the connectivity layer that communicates to the database and should be transparent. I think that some of the Data Access Layer that you are referring to is actually going to be handled in the business layer or related events.

RE: Code Snippet Editor

Alex Luyando — Fri, 14 Mar 2008 10:56:10 GMT

Good Morning!

After working with the trial a bit and comparing it to Visual FoxExpress and a custom framework that I've worked with in the past I wanted to discuss a bit further the use of an active Data Dictionary v. the BO Mapper to set properties and behavior for columns in a table. My most pressing concern has to do with the thought that setting these properties at the BO level can lead to the need to repeat the process for any "new" BOs that are created for the same table. Is that the case, or does the "*designer" file hold this metadata and therefore can be reused for other BOs that need it?

Also, (and this may reflect my ignorance of SF), VFE has a data layer that allows for PEMs at the column, cursor and DataEnvironment levels. Is there something similar in Strataframe?

Thanks.

RE: Code Snippet Editor

Alex Luyando — Thu, 13 Mar 2008 10:44:46 GMT

Good Morning, Trent -

Out with the old, in with the new. I like it!

RE: Code Snippet Editor

Trent L. Taylor — Wed, 12 Mar 2008 16:11:24 GMT

[quote]Guess two steps forward one step back (tell me it's not the other way). [/quote]

We too are from a VFP background and used to rely heavily on data dictionaries...which in our medical application we are doing everything that we can to get away from it! There are better (and more efficient) ways of accomplishing the same thing in .NET. One thing that most developers moving over from VFP have a hard time initially grasping is disconnected data. When we were developing in VFP, you opened a table and BOOM...all of your records were there. Even if you were using views it still had to bring the data to the client to do the work since there was not a server.

Relying heavily on a data dicitonary in a disconnected data application (which will be any application from this point forward) can create a slow and unresponsive application. Thus most develpoers take a different approach. It took us a while when we first stepped into .NET and disconnected data from VFP because we were trying to basically use the same techniques on a new technology....which just won't work...and it shouldn't.

I think that as you move forward you will discover hundreds of new things that will make your life much easier and better...so though at first glance it appears as though there has been a step back or two, that is just because we have generally been trying to look at it from the same perspective as when we were developing in VFP when there is ultimately a better and more efficient way in .NET.

RE: Code Snippet Editor

Alex Luyando — Wed, 12 Mar 2008 15:56:23 GMT

Wow.... very cool seeing some familiar names from the VFE forum... making me think we're doing the right thing by looking at SF.. :)

Any tips? Funny Charles' comment about the DBCX... we've started having discussions about the various frameworks we're looking at and I had mentioned that the lack of an active data dictionary is not so cool... Guess two steps forward one step back (tell me it's not the other way).

By the way, did you guys look at any other frameworks (e.g., CSLA or devForce)?

________________
_____/ Regards,
____/ al

RE: Code Snippet Editor

Charles R Hankey — Tue, 13 Nov 2007 06:20:43 GMT

Hey Randy

Well, I'm certainly to the point when I go back to the VFP debugger it is like looking at the FPW 2.6 debugger from VFP.

You and I have been spoiled in VFP by using VFE ( which has great design similarity with SF ). We've been using objectified data, SQL backends and business objects for years.

But I see from VB .NET books that there are a lot of .NET folks doing the equivalent of writing table based 2 tier VFP apps. I think SF is going to keep us going in the direction of best-practices in .NET the way VFE does in VFP.

I'm still having a little trouble warming up to .NET's idea of inheritance, but there are some cool parts ( partial classes ) that make it just different, not necessarily inferior.

The one thing I'm finding still weak in the .NET world ( though it probably has a lot to do with my incomplete understanding of the underlying architecture ) is data-driving processes - especially what appears to be the absence of a data dictionary on the level of DBCX2. I'm hoping the SF DDT evolves in that direction.

RE: Code Snippet Editor

Randy Jean — Mon, 12 Nov 2007 20:42:15 GMT

Very cool Charles. Thanks for posting this. So, have you got to the point where you say "Yuck!" when you have to go back to VFP? (I'm still not there yet but gradually I'm seeing the coolness of the VS IDE)

RE: Code Snippet Editor

Greg McGuffey — Wed, 07 Nov 2007 18:44:38 GMT

no kidding..."Duh"...I can't believe I didn't think of this! (smacks head on desk)

:blush:

Thanks!