CODE BEHIND -version of edit_bug.aspx (cbmod11)
Brought to you by:
ctrager
Menu
▾
▴
#31 CODE BEHIND -version of edit_bug.aspx (cbmod11)
hi folks,
It is not yet publishable, but I took the great step for the mankind and modifed the edit_bug.aspx
page into separate aspx and aspx.cs -documents to follow the code behind -system.
I saw that as a way to allow more flexible custom developments with the page.
At least our developers are asking for more shortcuts to all those dropdowns so that you could
more quickly create a work item of certain kind, to yourself in your current project etc.
I have some custom code included in the .cs, so before publishing, I would need
to make that more pluggable in that sense and also I still have a couple of code lines
left in the aspx too (but just a couple). And, the edit_bug.aspx -page base version that I am
using is 3.4.1 so that might need some updates too that i need to check out.
Let me hear if there is anybody interested in this. I just might get it out sooner.
Hi, I'd be pretty interested in this code. I've been meaning to add some shortcuts for some of our customers as well, but just haven't got around to it. Please share it with us.
Nice one.
Good to hear! I will try to get it out in april or in the firsts weeks of may. Currently I have been testing against the classic implementation behaviour and fixing differencies from the new implementation. I would say that about all of the functionality that we are using ( we are not using all customization capabilities) already work in the new model as expected.
Just updating status.
I have quite well isolated my other customizations and implemented most of them as new methods in Workflow.cs. Javascript-parts of edit_bug.aspx will remain as they were, but otherwise all Response.Writes have been translated into corresponding <asp:Label> which then is written from the code.
I am currently porting my codebase to 3.4.9 from 3.4.1 and so far everything seems ok, except that I have to diff old 3.4.1 and new 3.4.9 edit_bug.aspx and then update the differences into the code-behind model. I have marked all new items and code mostly so that their id:s start with "cbmod11" (code behind modification 2011). I hope Corey could consider including this to the official version for all people's benefit. I Expect to post this in schedule unless nothing unusual happens. Easter holidays gives good time for some serious coding :)
Hi,
The first version of this is attached. It should work with newest version of BT.NET which is currently 3_4_9.
Only the files that need modification are included and files under the btnet-directory. Remember to back up your working system before applying this patch. Furthermore: edit_bug.aspx is here by separate name: edit_wi.aspx and edit_wi.aspx.cs just to allow some testing side-by-side. When you feel confident, just rename these files into edit_bug.aspx and edit_bug.aspx.cs to make integration complete. (wi = work item).
Just updated the file package. There were some "not applicable anymore" warnings in comments that were not issues any more -> removed those. Testing feedback welcome.
I continued testing this package against clean 3_4_9 install and found 1 unnecessary left-over reference in workflow.cs that should have not been there (I just removed it) and I also removed one other leftover code-pair from the edit_wi.aspx and edit_wi.aspx.cs. Now I think this is ready for wider testing of you users out there. I would also like to mention, that the main principle in this migration was to maintain identifiable code fragments from the original model and this was done by converting many "Response.Write"s so that they now use a virtual ("RAM response") where they write and later the content of what was written is taken back as a string and put into place marked by appropriate new Label-object in the aspx.
screenshot of custom BT.NET edit_bug.aspx with other site-specific customizations such as a big ID-number text
another screenshot with this cbmod11 patch applied over BT.NET 3_4_9 ( with custom web.config though)
Updated the patch again.
in edit_wi.aspx.cs moved call to "Workflow.custom_adjust_oneachpageload(id, security.user, this );" from about line 195 (+-5) to line 857 (+-5), where dropdowns are always adjusted. This way it is easy to provide category-specific help from that workflow-function. If you for example have a category named "error-or-defect", then you could have a file "error-or-defect.html" in you App_Data-folder that contains a short help text for entering that kind of work item if you have the following code in that workflow function (Note: partial to show the point only):
... in function void custom_adjust_oneachpageload(..)
{
Label customhelpLabel = (Label)find_control(page.Controls, "cbmod11customhelptext");
if (customhelpLabel != null)
{
DropDownList ddlCategory = (DropDownList) find_control(page.Controls, "category");
string strCategoryHelpFile = page.Server.MapPath("App_Data") + "\\" + ddlCategory.SelectedItem.Text + ".html";
if (File.Exists( strCategoryHelpFile ))
{
customhelpLabel.Text = File.ReadAllText(strCategoryHelpFile) + "<br />Rendered: " + DateTime.Now.ToString();
}
else
{
// display default help here...
}
}
custom skinning example - metallic edit_bug.aspx form (not directly related to cbmod11 changes)
Updated the patch again.
- Removed most of remaining warnings related to edit_wi.aspx.
- Added "big ID" -display code for the workflow.cs.
- NOTE: there are still warnings about edit_wi.aspx (leftovers from the original code of edit_bug.aspx)
Status update: this code is now publishable.
Remember, that the main purpose and methodology in this migration has been to save structures that existed before the migration, so comparison and verification of the migration itself is easier.
The natural NEXT steps for the development would be to improve
the code structure itself: there is some leftover function from the orignal that
has about 800 lines(!) and a number of other places for improvement.
This is best to occur however once and if this base migration is tested and accepted by a wider audience than just me. I am quite sure that there are some issues to be found and fixed - that's just a basic wisdom in code development.
After publishing the latest version so far I noticed that I had forgotten two
my locally meant customizations in the code that forced disabling
of svn revisions and merger bug -menu choises.
These were on the lines 650-651 and 741-742 on the edit_wi.aspx.cs
and are now removed from the patch "btnet349_cbmod11_2011-04-28_0000.zip"
Currently - possibly already before - it is possible and recommended to do that kind of customization in the App_Code\workflow.cs
code behind version of edit_bug.aspx as edit_wi.aspx and edit_wi.aspx.cs (code structure as much the same as possible). For BT.NET 3_4_9
well, fixed one more mistake :), this time it was on the comment section only
Readers, please note that I have posted the NEXT STEP (CBMOD11B) version of this code in https://sourceforge.net/tracker/?func=detail&aid=3293897&group_id=66812&atid=1214931
The version in this post is good for validating the goodness of migration as it contains very similar function bodies compared to those in the original singular edit_bug.aspx. The NEXT STEP (CBMOD11B) in my other post is more revised version with smaller function bodies and it is therefore more difficult to compare it against the original one. For somebody wanting to check the whole thing, I suggest studying this first and only then continuing to the CBMOD11B.
- please note: i have now published CBMOD11C preview 1 here:
https://sourceforge.net/tracker/?func=detail&aid=3296523&group_id=66812&atid=1214931
9cNnXm <a href="http://vafrvkqgbyta.com/">vafrvkqgbyta</a>, [url=http://liicsrfzurnb.com/]liicsrfzurnb[/url], [link=http://velihkyucupo.com/]velihkyucupo[/link], http://gekjjgxipwns.com/
549vBU <a href="http://aclcfhxjlhlf.com/">aclcfhxjlhlf</a>, [url=http://oowqwkxdxdcv.com/]oowqwkxdxdcv[/url], [link=http://clzpdydralku.com/]clzpdydralku[/link], http://gyrzhdxznjji.com/